fix: restore yargs-parser compatible argument parsing - #913
Merged
Conversation
Tony133
marked this pull request as ready for review
September 8, 2026 07:48
Co-authored-by: Matteo Collina <hello@matteocollina.com>
2 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposal:
The migration to
util.parseArgs(f2738f5) dropped several behaviors of yargs-parser:Unknown option— the parser is now non-strict by default (strictonly when explicitlytrue), like yargs-parser.generate-swagger,eject, etc. pass through the mainargs.jsparser with options it does not know (--yaml=true).--hello world→hello: true). Nowhello: 'world'; a value starting with-is still treated as a flag.false:--watch=false,--watch false,--watch 0,-w falseare now honored.util.parseArgscannot express--bool=false, so the normalizer collects them and applies them after parsing.--was being re-normalized; it is now passed through untouched, so'--'and plugin options match the input.-r a -r b,--import) kept only the last value;start.jsthen crashed withopts.require.forEach is not a function. They are collected into arrays again fromtokens.helper.build('./plugin.js -- --hello world')relied on it.test/args.test.jsrestoreshello: 'world'(the migration commit had changed the expectation tohello: true) and adds tests for each case above.Test runner:
suite-runner.jsnever ran a single test:globwas bumped to v13 (#789) and the callback API no longer exists, soglob(pattern, cb)resolved a promise nobody awaited and the process exited 0. That is why CI stayed green through the regressions above. The runner now awaits the promise, exits 1 when no file matches, and ignoresnode_modulesand thetest/workdir*directories left behind by the generate tests.With tests actually running, two more environment issues showed up:
pkg-up@5,is-docker@4andchalk@6(bumped in chore: bump the dependencies group with 3 updates #896) are ESM-only. They are loaded throughrequire(esm)(.default/ named export); theis-dockermocks intest/start.test.jsare adjusted accordingly. Note: this requires Node ≥ 22.12 — if Node 20 must still be supported, these three dependencies need to be pinned to their CJS versions instead.@types/*automatically:types: ["node"]is added to the two test tsconfigs.unit:ts-esmfails on Node 24 with--loader ts-node/esmwhenrun()spawns the test files; it now usesmodule.register()via--import ./test/configs/register-ts-esm.mjs, which also removes theExperimentalWarning.Also:
generate-plugin.jsno longer writes an emptytstyche: {}when the template has none.Note:
concurrency: 1runner setting and the version-tolerantis-dockerimport come from there (co-authored with @mcollina).Closes #912