chore: bump yargs version

[Strum355]

Description

Yargs v17 doesn't support NodeJS 25 (which CI is testing with because we say to test with latest) bcoe/c8#582

Checklist

• I have followed this repository's contributing guidelines.
• I will adhere to the project's code of conduct.

[qodo-code-review]

Review Summary by Qodo

Bump yargs to v18 and update dependencies for Node.js 25

✨ Enhancement

Walkthroughs

Description

• Bump yargs from v17 to v18 for Node.js 25 support
• Update c8 from v10 to v11 for compatibility
• Add eslint-import-resolver-typescript dependency
• Expand CI testing to Node.js 22, 24, and 25
• Configure ESLint TypeScript resolver settings

Diagram

flowchart LR
  A["Dependencies Update"] --> B["yargs v17 → v18"]
  A --> C["c8 v10 → v11"]
  A --> D["Add eslint-import-resolver-typescript"]
  E["CI Configuration"] --> F["Node.js 22, 24, 25"]
  G["ESLint Config"] --> H["TypeScript Resolver"]

Loading

File Changes

1. package.json Dependencies +3/-2

Update yargs, c8, and add TypeScript resolver

• Upgrade yargs from ^17.7.2 to ^18.0.0
• Upgrade c8 from ^10.1.3 to ^11.0.0
• Add eslint-import-resolver-typescript ^4.4.4 as dependency

package.json

---

2. .github/workflows/test.yml ⚙️ Configuration changes +1/-1

Expand CI testing to Node.js 22, 24, 25

• Expand Node.js test matrix from ['24', 'latest'] to ['22', '24', '25']
• Explicitly test against Node.js 22, 24, and 25 versions

.github/workflows/test.yml

---

3. .eslintrc.json ⚙️ Configuration changes +1/-0

Configure ESLint TypeScript resolver

• Add TypeScript resolver configuration to ESLint settings
• Enable TypeScript support for import resolution

.eslintrc.json

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Unused TS resolver config 🐞 Bug ✓ Correctness

Description

.eslintrc.json adds a top-level settings.typescript key and eslint-import-resolver-typescript
is added, but the resolver is not configured under settings.import/resolver. Additionally, linting
is only run on .js files, so this change is likely a no-op and adds an unnecessary published
dependency.

Code

.eslintrc.json[R35-38]

+	"typescript": {},
    "import/resolver": {
      "node": {
        "extensions": [".js"]

Evidence

The ESLint settings add typescript at the root of settings, while eslint-plugin-import
resolver configuration lives under settings["import/resolver"]; the current resolver config only
enables the node resolver. Also, the lint script only lints --ext js, so a TypeScript resolver
configuration wouldn’t be exercised anyway. Finally, eslint-import-resolver-typescript is added
under runtime dependencies, which will be installed by consumers even though it’s only relevant to
linting.

.eslintrc.json[34-41]
package.json[37-57]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`eslint-import-resolver-typescript` was added, but ESLint is not configured to use it (and linting only targets `.js`), so the new dependency/config is likely a no-op.

### Issue Context
- The resolver is currently only configured as `settings.import/resolver.node`.
- The added `settings.typescript` key is not used by `eslint-plugin-import` resolver wiring.
- The dependency is in `dependencies` (published to consumers) though it’s only needed for linting.

### Fix Focus Areas
- .eslintrc.json[34-41]
- package.json[37-57]

### Suggested changes
1) If you want TypeScript resolver behavior for eslint-plugin-import, change to:
```json
"settings": {
 "import/resolver": {
   "typescript": { "project": "./tsconfig.json" },
   "node": { "extensions": [".js"] }
 }
}
```
2) Move `eslint-import-resolver-typescript` to `devDependencies`.
3) If TypeScript files should be linted, update the lint script to include `--ext js,ts` and add the required parser/plugins; otherwise remove the added resolver dependency/config entirely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. CI ignores npm engine 🐞 Bug ⛯ Reliability

Description

The repo declares engines.npm >= 11.5.1, but the CI workflow only installs Node and runs npm ci
without ensuring the npm version meets that requirement. Adding more Node versions in the matrix
increases the chance CI will run with an npm version that violates the declared engine constraint.

Code

.github/workflows/test.yml[R23-26]

+        node: ['22', '24', '25']
    env:
      MAIN_NODE_VER: '24'
    steps:

Evidence

package.json declares an npm engine constraint, but the workflow doesn’t pin/upgrade npm—only Node
is selected—before running npm ci. This means CI is not guaranteed to satisfy the project’s own
engine requirements across the expanded matrix.

package.json[19-22]
.github/workflows/test.yml[21-35]
.github/workflows/test.yml[82-84]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
CI does not enforce the repo’s declared `engines.npm >= 11.5.1` requirement; it installs Node and runs `npm ci` without pinning/upgrading npm.

### Issue Context
With a Node version matrix, npm versions can differ between Node releases. If the project truly requires npm >= 11.5.1, CI should ensure it.

### Fix Focus Areas
- package.json[19-22]
- .github/workflows/test.yml[21-35]
- .github/workflows/test.yml[82-84]

### Suggested changes
Option A (enforce): Add a step after setup-node:
```yaml
- name: Ensure npm version
 run: npm i -g npm@^11.5.1
```
(or pin an exact npm version).

Option B (relax): If npm >= 11.5.1 isn’t actually required, lower/remove the `engines.npm` constraint to match what CI uses.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Yargs bump lacks coverage 🐞 Bug ⛯ Reliability

Description

Yargs is a direct dependency of the shipped CLI, and this PR bumps it across a major version. The
CLI entrypoint is excluded from c8 coverage, so a yargs breaking change could ship without being
detected by unit tests/coverage checks.

Code

package.json[R49-56]

+		"eslint-import-resolver-typescript": "^4.4.4",
		"fast-toml": "^0.5.4",
		"fast-xml-parser": "^5.3.4",
		"help": "^3.0.2",
		"https-proxy-agent": "^7.0.6",
		"node-fetch": "^3.3.2",
		"packageurl-js": "~1.0.2",
-		"yargs": "^17.7.2"
+		"yargs": "^18.0.0"

Evidence

The CLI imports yargs directly, making the yargs major bump user-facing. However, the test command
runs mocha under c8 and c8 explicitly excludes src/cli.js, so the CLI won’t be exercised/guarded
by the existing coverage gate.

src/cli.js[1-8]
package.json[46-57]
package.json[85-98]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The PR bumps `yargs` to a new major version, and `src/cli.js` depends on it at runtime, but the CLI is excluded from coverage and is not exercised by the current test command.

### Issue Context
Current tests are run via `npm run test` which uses `c8 npm run tests`, and c8 excludes `src/cli.js`.

### Fix Focus Areas
- package.json[40-45]
- package.json[85-98]
- src/cli.js[1-8]

### Suggested changes
- Add a small test (or CI step) that runs the CLI in a non-networking mode, e.g.:
 - `node src/cli.js --help` (or `node src/cli.js component --help`)
- Alternatively, remove `src/cli.js` from c8 excludes and add a dedicated test file that imports/executes the CLI argument parsing in-process.

Goal: ensure yargs major-version upgrades are guarded by automated checks.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more