fix: context must be reset, or nested sub-commands fail on second invocation

[bcoe]

This addresses an issue @ceejbot ran into using headless .parse() in conjunction with nested sub-commands.

CC: @nexdrew

[nexdrew]

Hmm, the whole point of the generic context is to keep track of things that should not be reset. I honestly don't know how subcommands would work at all if we're resetting this, since it's used to determine which level of command is currently being executed and which files (for .commandDir()) have been visited (to account for potential cyclic directory refs).

I really need to test this thoroughly and would argue for a different solution.

[bcoe]

@nexdrew keep in mind that the only time we reset the context object is in-between distinct runs of

.parse(rawArgs, context, parseFn)

The nested command handlers do invoke .parse() but they invoke it without parseFn; so unfreeze will not be executed until the entire stack has popped.

[nexdrew]

Ok, resetting the "context" makes more sense in the unfreeze() function (as opposed to the reset() method), but, at the risk of sounding silly, I must admit this has me baffled; I don't see the connection between the parseContext var (set from the 2nd arg to .parse() and applied to argv for the command handler) and the context var (private state used for subcommand scoping, never applied to argv) at all.

[bcoe]

@nexdrew did a bit of digging, this is the underlying issue here:

      if (visited) {
        // check for cyclic reference
        // each command file path should only be seen once per execution
        if (~context.files.indexOf(joined)) return visited
        // keep track of visited files in context.files
        context.files.push(joined)
        self.addHandler(visited)
      }

Because files is left in the context object, on the next run of the parser we don't re-add handlers.

[nexdrew]

Ok, wow, good find. I didn't realize the problem is specific to a command that uses .commandDir() in its builder function. This makes sense now.

(Also, I apologize for my presumptive knee-jerk reaction! 😔 I should have taken more time to understand/diagnose the problem before responding. Thanks for keeping a level head and finding the root cause for us, which you have now had to fix twice! 😳)

Let me do a bit of experimenting to see if I can make the context management more robust. Otherwise, we could get away with simply resetting the context.files array.

[nexdrew]

@bcoe See #680 (which is a PR against the nested-command-fix branch) for my preferred solution to this problem. If you're ok with it, we can merge 680 first and then merge 678.

[nexdrew]

LGTM! I vote merge once we confirm the new test passes.