Repository navigation
node.config.json doesn't respect optionally-valued or aliased options #57960
Description
Activity
Inspect option is reaching the boolean case:
Line 56 in e9b286c
When a non-boolean is provided, it displays the error
Invalid value for --inspect. When providing a boolean, it does this--inspect=truewhich cannot be interpreted by, since whan a value is provided it expects a host:port (https://nodejs.org/api/cli.html#--inspecthostport)node/src/inspector_socket_server.cc
Line 402 in e9b286c
It expects an hostport value, if you pass any other value it will throw an error
It expects an hostport value, if you pass any other value it will throw an error
It should also accept
true, to enable inspection on the default port. Regardless, if any non-boolean value is passed, it'll fail validation withnode.config.json: invalid content.Even in the schema it expects a boolean:
"inspect": { "type": "boolean" },
Probably
env_options_mapcontains the same value twice with different accepted types. This behavior is currently not supported. PR welcomeWill give it a try, folks
So I don't think this is a config bug.
For example:marcoippolito@marcos-MacBook-Pro-2 node % NODE_OPTIONS=--inspect=true node -p '1' Unable to resolve "true": unknown node or service 1The error is thrown by the
--inspectflag not by the config parser.
If you want to it to support a boolean value the--inspectimplementation needs to be changed.
In the config since its a json you cannot leave the value empty.
Usingnullcould be interepreted as a value so 🤷🏼
The weird part is thatinspectexpects a boolean value but it cannot parse it 😆you are correct, it's on inspect side
At first, I wanted to turn --inspect=true into --inspect in the config implementation. But maybe going directly in the inspector is a more reasonable approach.
Reacted by Aviv KellerI was dealing with this problem just today and i cannot figure out why until i found this open issue :D
Anyway, i had same problem but using --inspect-wait flag, so i go through the code and i found that the problem afflicts all inspector options:
--inspect=--inspect-wait=--inspect-brk=--inspect-brk-node=// Defined but not callable from cli, so not an issue (for now)
But NOT
--inspect-port=itself (which expects a string value).Here some runs:
$ node -v v23.11.0 # The problematic case - inspect flags with boolean values $ NODE_OPTIONS=--inspect=true node -p '1' Unable to resolve "true": unknown node or service 1 $ NODE_OPTIONS=--inspect-wait=true node -p '1' Unable to resolve "true": unknown node or service 1 $ NODE_OPTIONS=--inspect-brk=true node -p '1' Unable to resolve "true": unknown node or service 1 # But this works fine $ NODE_OPTIONS=--inspect-port=true node -p '1' 1
@geeksilva97 there's something in the code that look me a little bit strange and i was not able to debug it effectively (due my lack of c++ knowledge):
File: node_options.cc
Method: DebugOptionsParser::DebugOptionsParser())AddAlias("--inspect=", { "--inspect-port", "--inspect" }); ... AddAlias("--inspect-wait=", {"--inspect-port", "--inspect-wait"}); ... AddAlias("--inspect-brk=", { "--inspect-port", "--inspect-brk" });
that invoke this AddAlias method that seems doing 2 things:
- Set
--inspect-portto"true" - Enable `--inspect
😕
And, another bigger problem that i see is the misconception of how we always used --inspect option, it seems that it was originally though to get just a boolean as input, but we always used passing host:port.
As you can see:--inspectis defined as a boolean option (&DebugOptions::inspector_enabled)- But
--inspect=truedoesn't work because the alias tries to parse "true" as a host:port - In JSON config files, you can't leave boolean values empty, so
"inspect": trueis the logical way to specify it, but it's not what cpp expected.
So, who's wrong? the cpp implementation of inspect, the parser or the documentation?
Hope this research it will help to fix the issue.
that invoke this AddAlias method that seems doing 2 things:
Set --inspect-port to "true"
Enable `--inspectHi @thisloke . You are correct on this
When you execute
node --inspect=trueis expands tonode --inspect-port=true --inspectthat's why it gives that error.
i see is the misconception of how we always used --inspect option, it seems that it was originally though to get just a boolean as input
In Node, boolean options don't need an input. The way to enable disable an options is with the
--noprefix. You can see more details about it in this comment. So,--inspectis indeed a boolean. It doesn't need an input.In JSON config files, you can't leave boolean values empty, so "inspect": true is the logical way to specify it, but it's not what cpp expected.
That's what my PR addressed. You should be able to have
"inspect": true"in your config file since version 24.0.0Reacted by Lorenzo Iovino and Aviv Keller@geeksilva97 amazing, so i think it will also solve the problem with
--inspect-wait=trueand--inspect-brk=truebecause the issues was how--inspect-port=truewas expanded and both (-wait, -brk) expanded also--inspect-port=trueand now they will just expand--inspect-portinstead.Reacted by Edy Silva@geeksilva97 amazing, so i think it will also solve the problem with
--inspect-wait=trueand--inspect-brk=truebecause the issues was how--inspect-port=truewas expanded and both (-wait, -brk) expanded also--inspect-port=trueand now they will just expand--inspect-portinstead.Yeah, most likely. You can let me know about any issues
Closing again since I accidentally reopened it
Version
v23.11.0
Platform
Subsystem
No response
What steps will reproduce the bug?
Create a
node.config.jsonwith the following content:{ "nodeOptions": { "inspect": true } }Run:
How often does it reproduce? Is there a required condition?
N/A
What is the expected behavior? Why is that the expected behavior?
The expected behavior would be that the configuration file understands that setting a flag to
trueis the equal to applyingnode --flag, whereas setting a flag to an alternative value is the equal of applyingnode --flag=value, even for aliased options.What do you see instead?
When supplying
true,When supplying a string value, like
127.0.0.1:Additional information
No response