Validate CLI flags

[mrazauskas]

Thanks for CLI improvements!

Here is another idea. I have noticed that it is too easy to make a mistake like this: poku --failFast. The failFast is primarily documented using camel case (look at TOC, or heading of the page). Or someone (like me) might be used to run tests with --failFast.

It would be useful to see some error like: Unknown flag --failFast.

Edit: And another mistake I just made: poku --paralel.

---

Support for camel case flags is another feature, but I will mention it here too. Interestingly tsc supports only camel case flags. That simplifies documentation of compiler config options and CLI flags.

[wellwelwel]

Hey, @mrazauskas 🙋🏻‍♂️

I'd have no problem patterning the camelCase, but it would be more feasible in a future major version (v3).

As for validation, it's a good idea.

[mrazauskas]

Sure. This issue is about validation only.

The rest is totally up to you. Since that is opinionated and also depends on how you see Poku's future.

[mrazauskas]

I understand this is not a priority right now. Just to draw you attention: not only flag names, but also their values need validation; the same is applicable for config file options.

For example, imagine some option being removed / renamed / changed its behaviour.

Perhaps it is worth to keep this issue open?

[wellwelwel]

In a way, this functionality would frequently imply breaking changes. So, to have more flexibility, I released it as "Early Development" and documented some plans for the enforce option:

poku/website/docs/documentation/poku/options/enforce.mdx

Lines 27 to 29 in 3cb5a00

	- [x] Forces an error if any _CLI_ flags are invalid.
	- [ ] Forces an error if no file is found _(soon)_.
	- [ ] Forces an error if the environment has multiple platforms and the `--platform` option isn't explicit _(soon)_.

values need validation; the same is applicable for config file options

• More ideas are welcome 🙋🏻‍♂️

Also:

poku/website/docs/documentation/poku/options/enforce.mdx

Lines 39 to 41 in 3cb5a00

	:::info
	This feature will be included in the configuration file when the development stage is stable.
	:::

---

Perhaps it is worth to keep this issue open?

For now, I'm using the documentation itself as if it were an issue (with the idea of emphasizing that this feature is still under development). Honest question, do you think this is a bad idea?

[wellwelwel]

For example, imagine some option being removed / renamed / changed its behaviour.

About this, I tend to take versioning pretty carefully, for example, to make it easier to migrate on camel case, I've allowed both kebab and camel cases until a new major version is actually released.

Despite that, the intention is for the enforce to notify depreciated options. For example, even allowing fast-fail, when using enforce it will throw an error because it expects for failFast.