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
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. |
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