Repository navigation
util.parseArgs() omits the first positional argument when used with the --eval= option #60808
Description
Version
v25.2.1
Platform
Linux DESKTOP-O26JEMV 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Subsystem
No response
What steps will reproduce the bug?
node --eval="import {parseArgs} from 'node:util';console.log(parseArgs({allowPositionals: true}))" -- arg1 arg2How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
{
values: [Object: null prototype] {},
positionals: [ 'arg1', 'arg2' ]
}
What do you see instead?
{ values: [Object: null prototype] {}, positionals: [ 'arg2' ] }
Additional information
No response
Activity
ljharb commentedon Nov 22, 2025
hmm, this is specifically accounted for in the code.
Renegade334 commentedon Nov 22, 2025
Looks like
--eval ...is covered, but--eval=...isn't.azadgupta1 commentedon Nov 22, 2025
I would like to work on this issue.
I’ll start investigating the
--eval=case where the first positional arg is skippedand will share findings or a draft fix soon.
IlyasShabi commentedon Nov 22, 2025
I think that the issue is:
--eval "code"we store it inprocess.execArgvas TWO separate items['--eval', 'code']--eval="code"we store it as ONE item['--eval=code']We should check if any item
execArgvstarts with--evalnot just exact match as we do today.@azadgupta1 If you're willing to fix this the function you need to modify is getMainArgs()
Nb: This bug affects both
--eval=and--printLet me know if you need any help
Renegade334 commentedon Dec 11, 2025
Resolved by #60814.