Intern CLI review

[jason0x43]

The goal of this issue is to define how Intern's CLI should behave and what capabilities it should support.

The current CLI is very simple and behaves in some non-standard ways, particularly in how it handles command line args. It should probably behave more like other CLI apps (standard arg format, sub commands, etc.). However, there may also be some advantage in maintaining compatibility with the existing arg format since it closely mirrors the query arg format used in the browser (it's also slightly easier to use with npx).

Some questions to answer:

• How should the CLI interact with Intern? (load directly vs run in a separate process)
• Will it support pluggable functionality similar to Dojo's CLI?
• How should the CLI present Intern options such as reporter selection? For example, Intern currently makes reporter selection very explicit, but usability might be improved if the CLI presented higher-level options (e.g., --junit-report to produce a JUnit report rather than having the user specify that a JUnit reporter should be used).

[jason0x43]

theintern/cli#6 suggests having intern's serve command open a browser by default. I personally dislike tools that open browsers automatically, but I could see making this a configuration option, or supporting an environment variable like CRA's BROWSER.

[jason0x43]

The end result of #950 was the suggestion to add a suite filter that would allow the configured suites list to be filtered by file name. This would allow users to easily execute one or more suites from the configured list of suites with a simple string. It would differ from grep in that it operates on filenames, and it would be different from using the suites setting because it would operate on the already configured suites list rather than the filesystem directly.

[jason0x43]

Handling nested config properties through CLI args

There's a straightforward mapping from command line args to top-level config properties. For example, --suites currently corresponds to the suites config property. We don't handle deeper properties very well, though. If you want to change node.suites, historically you'd have to pass a JSON value for the top-level property, like intern node='{"suites":"whatever"}'.

Intern should provide a way to consistently reference deep config properties through command line args. Possibly it could interpret dash-separated words as separate levels, or simply accept dot-separated values.

> intern --node-suites tests/node/*.ts
> intern --node.suites tests/node/*.ts

[jason0x43]

Another issue to add:

Add shell-completion scripts

Intern should include and/or be able to generate shell completion scripts for at least bash and zsh.

[jason0x43]

We should consider switching from commander to oclif for the CLI. It would give us several useful bits of functionality, such as prompting for input (needed for #1130), auto-generated shell completions, and activity indicators (this would be great during test startup). It also supports plugins, so we could allow for extensions similar to dojo's CLI.

[jason0x43]

Or we could just add special purpose packages as we decide specifically what we need. clui, inquirer, that sort of thing.