Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Subcommand Holds onto _optionValues Between Executions #1829

Closed
manunamz opened this issue Dec 5, 2022 · 2 comments
Closed

Subcommand Holds onto _optionValues Between Executions #1829

manunamz opened this issue Dec 5, 2022 · 2 comments

Comments

@manunamz
Copy link

manunamz commented Dec 5, 2022

I am setting up some unit tests around a commander.js cli tool. I verify that the args and opts the program is holding onto internally matches expectations for each test. It seems that subcommands, and possibly the Command object in general, is holding onto options between executions.

This means, if I test a command with options and then test the same command without any options, the second test will still have the options from the first execution.

// test with options pass
program.parse(['program', 'command', '-o', 'stuff']);
// test without options still have previous options
program.parse(['program', 'command']); // '-o' and 'stuff' will still be parsed

I am currently working around this issue by manually clearing options between each test -- see the following:

  afterEach(() => {
    const cmd: any = program.commands.find((cmd) => cmd.name() === 'command');
    cmd._optionValues = {};
  });

This is just a short description to notify the commander.js maintainer. I think the issue is probably a simple reset of _optionValues or class properties more generally...If more detail is required, I can fill out a more detailed ticket upon request.

@shadowspawn
Copy link
Collaborator

shadowspawn commented Dec 5, 2022

Thanks for the clear description.

Yes, there isn't any code to reset state after calling .parse(). The intended pattern is make a new Command for each test.

Related: #438 #1565 #1819

@manunamz
Copy link
Author

manunamz commented Dec 16, 2022

Thanks for the issue numbers! The relevant conversation is useful, particularly comments here and here.

Seems like a duplicate, so I'll close this out. Thank you again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants