🚧 Dev ➾ Determine why yargs is not returning what's expected

[mweichert]

🔗 Epic|Feature Link

No response

🚥 Definition of Done

• [ ] 🎯 Planning and Design
• [ ] 🏎️ Dev Implementation Complete
• [ ] ♾️ PR Merged
• [ ] 🏆 Product Acceptance

🧰 Work Description

In the CLI, we parse arguments from the CLI twice.

• In our first run, we configure a yargs instance that is aware of all global options and tasks. We then parse against this yargs configuration to determine whether a global task was involved. If so, we execute that task and end the process.
• In our second run, we have determined that a global task isn't to be executed. The ephemeral state is loaded so that we can configure a new yargs instance that is aware of all plugin provided tasks. We then parse against this yargs configuration to determine whether a plugin-provided task was requested.

However, there was a problem found during the internal-tasks-refactor work (#1613 ) in the second run of parsing.

Yargs is used to parse CLI arguments into commands, positional arguments, and option flags.

After yargs parses the CLI arguments, an object representing all options is returned. The command (or in Taqueria terminology, the "task") being invoked is stored in the '_' property. If you were to execute the 'generate types' task, then ')' would be set to ["generate", "types"].

In the first pass of parsing arguments, the '' property is set to as what we would expect: ["generate", "types"] In the second pass of parsing, the '' property is truncated for some reason: ["generate"]

Note, this is also present in main, and seems to have existed for a while, but only manifested in the internal-tasks-refactor work. The reason being is that the logic of the tasks refactor branch utilizes the '_' property to determine what task is being invoked. In main, we utilize yargs command handlers, which fork execution outside of the main execution pipeline.

To get around this at the moment, we just copy the '_' property from the initial pass of parsing arguments to the object resulting from the second pass of parsing. See here: https://github.com/ecadlabs/taqueria/blob/refactor-internal-tasks/cli.ts#L1125

✅ To Do

• [ ] Determine why the second call to parseArgs returns an object with the '_' array truncated
• [ ] Apply a better solution

⚖️ Acceptance Criteria

We should know why parsing using yargs behaves this way, and remove any hacks that force things to work.

🔭 Scope

Forking yargs.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[egarson]

What is the status of this?

[mweichert]

This is an exisiting issue, but its mitigated by the hack implemented above. For that reason, I'll consider this low priority.