Main command and subcommands have different default values

[Fd929c2CE5fA]

program.version("")
	.option("-s, --size", "size", "1")
	.action(() => {});
program.command("b")
	.option("-s, --size", "size", "5")
	.action((options, command) => {
		console.log(command.optsWithGlobals()); // method A
		console.log({options, ...program.opts()}); // method B
		console.log({...program.opts(), options}); // method C
	});

When a main command and a subcommand have the same options, they are consumed by the main command and never passed to the subcommand.

I know that we can generally use command.optsWithGlobals() to combine the results, but if both have different default values, the main command default value is always used when no parameters are given. This means the subcommand default value is ignored. That is, the result of optsWithGlobals() is similar to method B.

But if method C is used, user input is always overwritten by the subcommand default value.

My expectation are:

• Define the same option in the main command and subcommand but with different default values
• Print different default values ​​when using command -h and command b -h
• Use the default values ​​of each command if the user doesn't specify a size option
• Always use the user's input when user have specifying the size option

Currently there doesn't seem to be a default or elegant way to achieve this.
I was able to get it to work by just doing custom processing in .hook("preAction".
But I think this might be an issue that should be noticed.

[shadowspawn]

Thanks for the example code and description.

By default, options are global. So as you saw, the program option is masking the subcommand option. However, you can change the behaviour.

Have a look at the Parsing Configuration section in the README: https://github.com/tj/commander.js?tab=readme-ov-file#parsing-configuration

You can call .enablePositionalOptions() on the program. This makes two size options available, so you can use either or even both. This make sense if there really are two size options and not just different defaults.

(If what makes more sense is one size option, but with a different default when used with the subcommand than without an explicit subcommand, there is a different approach for that. You can define a default command which has its own options: #1616 #1750)

[Fd929c2CE5fA]

You can call .enablePositionalOptions() on the program. This makes two size options available, so you can use either or even both. This make sense if there really are two size options and not just different defaults.

Thank you very much! I remember reading this, but I hadn't recalled it. It seems like a promising option. However, I'm wondering if enable positional might have some side effects. For example, would other global options defined only in the main command also need to come before the subcommand? If so, I don't think that is what I'm looking for. This loses some ease of use. (I think that might be why I chose not to use it initially)

(If what makes more sense is one size option, but with a different default when used with the subcommand than without an explicit subcommand, there is a different approach for that. You can define a default command which has its own options: #1616 #1750)

isDefault presents a similar problem to the one I worried about above. I want global options to be shared so I don't need to define them redundantly in every subcommand. However, perhaps a subcommand will override the defaults value of several global options. So, turning the global command into another subcommand is not the intended approach.

---

By the way, if it helps anyone, here's how I currently solve the problem with a hook:

.hook("preAction", (thisCommand, actionCommand) => {
	if (thisCommand === actionCommand) return;
	for (const option of thisCommand.options) {
		const attr = option.attributeName();
		const value = thisCommand.getOptionValue(attr);
		if (value === undefined) continue;
		if (thisCommand.getOptionValueSource(attr) === "default") continue;
		actionCommand.setOptionValue(attr, value);
	}
})

[shadowspawn]

I agree my suggestions don't give you quite what you want! Nice use of the hook to "upgrade" the default value.

[Fd929c2CE5fA]

Yeah, the idea is to pass through non-default global option values (mainly user input) ​​to subcommand options.

I partly think this may should become some kind of default behavior, if it doesn't conflict with other use cases.

I would like to thank you for enlightening me on the use of hooks and allowing me to find a solution to this issue.

[shadowspawn]

Yeah, the idea is to pass through non-default global option values (mainly user input) ​​to subcommand options.

(Oops, yes, I did not describe it accurately.)

[shadowspawn]

I partly think this may should become some kind of default behavior, if it doesn't conflict with other use cases.

It means the help shows different default values in the program help and the subcommand help, so creates a minor inconsistency.

[Fd929c2CE5fA]

It means the help shows different default values in the program help and the subcommand help, so creates a minor inconsistency.

Yes, this is what I expected it to happen and why I redefined the same options in the subcommand so it shows up in the subcommand help.

And I think the inconsistency also exists in the isDefault approach, however it is at least more consistent with the expected use than ignoring the default value of the subcommand.

I think the main development expectations here are:

• We should have shared global options so we don't have to redundantly define the same things in every subcommand
• We should allow subcommands to override global options since this is an explicitly specified context