lookup: add yargs#1106
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1106 +/- ##
=======================================
Coverage 96.36% 96.36%
=======================================
Files 29 29
Lines 2203 2203
=======================================
Hits 2123 2123
Misses 80 80 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
ljharb
left a comment
ljharb
left a comment
There was a problem hiding this comment.
good start; we should absolutely be testing yargs 16, 17, and 18 (any major that supports non-EOL nodes)
|
Realistically, I do not think Yargs 18 is currently a good candidate for CITGM. The combination of no lockfile and low activity means builds can be broken for long periods: yargs/yargs#2393
|
|
It's still pretty important to know when a new node release will break it - node 26 breaking yargs 16 and 17 should have delayed the release imo. |
|
FWIW yargs is already covered in citgm through babel https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/3724/nodes=ubuntu2404-x64/testReport/junit/(root)/citgm/_babel_core_v7_29_0/
I think there's a misunderstanding about what CITGM does. Failures in the CITGM wouldn't stop an intentional breaking change from landing on semver-major release, given that:
It has the potential of stopping non-semver-major changes from landing on an existing release, or notifying package authors about the breakages in an upcoming semver-major release, though again these still depend on whether anyone volunteers to look at the CITGM results and follows up on it, and whether package maintainers are on top of maintenance. If the maintenance of of a package is not responsive, then adding it to CITGM only makes CITGM even more red, and make it even less likely for volunteers to look at the failures carefully. Given the stalling of yargs/yargs#2514 , yargs currently fails this hard requirement of adding it to CITGM
The reason why CITGM wasn't being looked at carefully is also due to having too many broken packages for a long time since the last bankruptcy: #959. Merging this PR is unlikely to change anything, considering the breakages is already in CITGM. For CITGM breakages to realistically block any release again, a volunteer would likely need to do another bankruptcy to restore the trust in CITGM, during which unresponsive packages need to go. |
I don't think it is a misunderstanding, it is aspirational that it does help avoid what happened when this change was released in a minor then reverted.
I do not believe it is good to rely on transitive usage. If
Right, this is what I offered to fix. I depend on
I can't speak to this, but many of the packages which were removed in the bankruptcy were added back. So I think those kind of wake up moments are when folks show up to do this work. Hence me being here asking for If y'all want to close this because of the problems, that's fine but it does mean less test coverage over critical use cases leading to more breakage in minors (like happened with this). |
Not sure if I am following - it didn't help in 25.7.0, otherwise it would not have gotten released in 25 at all (as it should've shown in the CI through babel before the release)
While I agree, I meant that if transitive coverage was already not functional, direct coverage would not have made a difference either.
To make CITGM trust-worthy again, what we need is to remove broken packages, not adding more broken packages. yargs survived the last bankruptcy because it wasn't broken back then. Adding two more broken versions of an unresponsive package on top of the existing 20+ is not going to help restore the trust in CITGM. I think to actually make this PR work as intended, two things needed to happen
Without those, this PR would be mostly a placebo. The (transitive) coverage of yargs was already neglected in practice. Increase of coverage does not guarantee voluntary attention to the breakages, or on the contrary, coverage of unresponsive packages is likely to warrant further lack of attention. |
|
I would expect CITGM to always be run, especially in a semver-major - it's just that breakage may be expected. |
|
I think to ensure CITGM is run and properly inspected, there needs to be more volunteer that run CITGM (e.g. using rcs or nightlies) and analyze the results themselves during the releases, and take on the work to notify and coordinate with package maintainers, since the current volunteers helping out don't necessarily have capacity to take care of CITGM carefully, especially for major releases that are already difficult and keep getting postponed due to various build issues (the April releases were already postponed to May two years in a row ultimately due to lack of hands, for example). There also needs to be more volunteers who take on active maintenance to keep CITGM green and produce trust-worthy results without diverting efforts consumed by other issues during releases. |
5 participants
Due to yargs/yargs#2509 I believe
yargsshould be in CITM.Currently it is failing because
yargsdoes not ship a lockfile and usesprettierso it pulls inprettierbreaking formatting changes intolint. I can open a PR to address this inyargsor we can excludelinthere whatever folks prefer (obviously easier to fix here).Additionally, I think the issue that occurred was on
yargs@17not18. Do we have precedent for testing multiple majors? I coudln't find any, but honestlyexpressshould have this as well until we can EOL v4. So any pointers on that would be great and I can open PRs for that.Output from `citgm yargs`
cc @bcoe @shadowspawn @nicolo-ribaudo
Checklist
npm testpasseshere