[JoaoMarcos44]

With strict: true and allowNegative: true, an explicitly declared negative boolean can overwrite a string option with false or write to an undeclared destination. This change validates those cases while preserving supported boolean negation and short aliases.

The configuration conflict check runs in the existing per-option validation loop, reusing the validated optionType. It rejects an enumerable own no-X: boolean declaration paired with an own X: string option, even with args: []. A separate usage check rejects an applied negation whose destination is not a declared boolean. An isolated no-alpha declaration can still be negated through --no-no-alpha.

storeOption() is unchanged. No new public option, dependency, cache, or abstraction is introduced. The additional pass over own property names has been removed.

Compatibility

• The configuration check follows the existing loop's enumeration scope. A non-enumerable negative declaration is not rejected while unused, but applying it to a string destination is still rejected by the usage check. An own non-enumerable destination is checked when the negative declaration is enumerable.
• A conflict can be reported before an invalid declaration that appears later. Each negative declaration's own fields are validated before checking its conflict.
• The negative declaration's validated type is reused; the destination is still read. This change does not guarantee getter or proxy evaluation counts.
• strict: false, allowNegative: false, valid boolean aliases, tokens, defaults, multiple, and literal negative string options retain their behavior in the covered cases.

Validation

• 176/176 tests passed on Node v22.16.0 and v24.22.1, including CLI cases, with no skips.
• All 117 tests from the upstream base are retained unchanged. Added coverage exercises conflicting declarations, missing destinations, invalid target configurations, aliases, double negation, and the enumeration behavior described above.
• Against the base module, the same suite produced 156 passes and 20 expected regression failures, checked by name and count. Against the previous PR revision, it produced 172 passes and the four expected differences.
• Repository ESLint (with the Windows linebreak-style exception), Markdown lint, and git diff --check passed.

The full parseArgs test entry point and original common helpers ran against the edited JavaScript module loaded with the installed runtimes' internals. These results are not from a rebuilt Node binary. A native build and the official CI remain pending.

AI assistance: Codex assisted with implementation, tests, review, and documentation.

Fixes: #67085

[github-actions]

Welcome to Node.js, and thank you for your first contribution!

Before review, please take a moment to read:

• the guide for first-time contributors
• the contribution and automation policies
• the pull request guide
• the AI use policy
• the Code of Conduct

Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal.

[ljharb]

As I commented in the issue, I think the existing behavior is expected, intentional, and desired. Having a --no-x option without also supporting an --x option is wildly unintuitive and confusing, and I think it's fine if node chooses not to enable that.

[JoaoMarcos44]

@ljharb I've narrowed this PR in 3d3d676. storeOption() now matches the base, so the established negative boolean alias behavior is preserved.

The change is confined to checkOptionUsage() in strict mode. After validating the original option and its argument, it checks the destination of an actual negation. A string or undeclared destination now throws ERR_PARSE_ARGS_UNKNOWN_OPTION. This also rejects explicit negative boolean options without a declared destination, rather than returning an undeclared key. strict: false, allowNegative: false, and literal no-* string options with values keep their existing behavior.

Added 18 regression and compatibility cases. Local verification against the edited JavaScript module passed all 126 API cases; the base fails the six new regressions. Repository ESLint and whitespace checks passed. The full rebuilt Node CI remains pending; the local test-runner limitation is documented in the description.

The issue description and infographic have also been updated to reflect this scope. AI assistance and the verification limits are disclosed in the PR description.

[ljharb]

It should not be possible by default with allowNegatives to reject --x and allow --no-x. That would be a poor API design, and something you should do on your own after parseArgs completes.

[shadowspawn]

checkOptionUsage is a runtime check that an option is being used as intended on the command line, so checking the arguments being parsed.

I think the restriction that declared explicitly negated booleans must not have a declared positive string option when allowNegative: true belongs in parseArgs() where the configuration is checked.

See the code following this line:

node/lib/internal/util/parse_args/parse_args.js

Line 313 in d44625a

// Validate input configuration.

[JoaoMarcos44]

Thanks, @shadowspawn and @ljharb. I've updated the PR in cdda2e3b.

The explicit no-X: boolean / X: string conflict is now checked during configuration validation, after the existing validators and before tokenization. It throws ERR_INVALID_ARG_VALUE even with args: []. The check remains under strict && allowNegative to preserve permissive parsing.

The missing-destination check stays in usage validation. Declaring no-alpha alone can still be valid for --no-no-alpha, while using --no-alpha without a declared alpha is rejected in strict mode. This keeps the two responsibilities separate and preserves both goals of the PR.

Application-specific logging behavior and normalization remain outside parseArgs(). There is no new coercion API or configuration flag; valid boolean aliases, tokens, defaults, and multiple remain covered.

Local verification passed all 167 parseArgs tests, including CLI cases, on Node v22.16.0 and v24.22.1. These runs loaded the edited JavaScript module with the installed runtime's internals; they were not rebuilt Node binaries. Repository ESLint and Markdown lint also passed. A native build and official CI remain pending.