Subcommands broken if bin name is different from name of script it resolves to

[jd20]

When using subcommands, you may have a list of scripts like:

cli.js
cli-search.js
cli-parse.js

You might then supply a bin field like:

"bin": { "mytool": "cli.js" }

However, this does not work with subcommands, as Commander.js will search for mytool-search.js, mytool-parse.js, etc... For some projects, renaming all the scripts to be the same as what's in the bin field may not be a viable option.

This fix adds additional logic to check if the symlink in bin resolved to a different name, and if so will use that name only if the regular logic fails to find the subcommand. Thus, this change should not affect cases that were already working before, it would only affect cases that were broken (the new logic is only invoked when Commander.js would bail out after failing to find the subcommand script).

I've also added a test case, which verifies that the new behavior is working properly.

[shadowspawn]

I am leaving this one out of v3 in favour of #854, but would like to come back in future and take a deep look at the name resolution for executables with this Pull Request as one of the likely improvements. No action likely in meantime.

[shadowspawn]

The related code has changed significantly, so this PR will need reworking. I am ok with the concept. :-)

I wonder whether it would be better to recursively call executeSubCommand with the new name, to get all the parsing logic?

[shadowspawn]

@jd20
Are you interested in working more on this?

[shadowspawn]

There is at least a manual work-around now with the executableFile option for commands. Closing this PR as inactive with conflicts.

Thank you for your contributions.