Can't use --help option

[rightaway]

When I run intern-client --help to see the options (for example to find how to enable parallel execution of tests), it throws an error:

Error: Missing required argument "config"
  at PreExecutor.getConfig  <node_modules/intern/lib/executors/PreExecutor.js:132:11>
  at getConfig  <node_modules/intern/lib/executors/PreExecutor.js:359:17>
  at <node_modules/intern/node_modules/dojo/Promise.ts:393:15>
  at run  <node_modules/intern/node_modules/dojo/Promise.ts:237:7>
  at <node_modules/intern/node_modules/dojo/nextTick.ts:44:3>
  at doNTCallback0  <node.js:428:9>
  at process._tickCallback  <node.js:357:13>

[jason0x43]

There is currently no --help option. There aren't many commonly used command line arguments; most configuration is intended to happen in a config file, which is a mandatory argument. A more helpful default message would be useful, though.

[sholladay]

I also think the CLI ought to get a makeover. Even --version doesn't work.

[jason0x43]

I agree, the command line interface could use some love.

[sholladay]

Going to collect some thoughts on the CLI here. Happy to file separate tickets if its helpful.

Problems

1. Newcomers on my team have been confused by the distinction between "client" and "runner". Not helping matters is that there is a Node.js client and a browser client, which aren't really related, and the "intern-client" command line tool only deals with one of them.
2. Somewhat related to number one, most people expect one CLI with some flags. It takes a while to stop trying intern --runner, etc. even if they understand which one they should be using. I imagine a simple intern command that defaults to runner and uses the tunnel from https://github.com/theintern/digdug/issues/19 as a very clean out-of-the-box experience.
3. Conventional flags like --version, --help don't exist.
4. config is required, even though Intern is pretty good at having defaults that Just Work. In many cases all it truly would need is probably a path glob for some tests. Any information it needs to share with the browser client could be handled by Intern's proxy, a temp file, or some other means that I wouldn't have to know about
5. There is no "set up" / init command to help people get started. This could be as simple as a mv from node_modules/intern/tests/example.intern.js to the default location where Intern expects it. Or it could be as feature rich as an Inquirer prompt that builds a config file for you. And/or Intern could have an official Yeoman generator.

[jason0x43]

I like where you're going here. My thought for this was to provide a new intern script alongside the existing intern-client and intern-runner scripts (we'd keep the old ones for now for backwards compatibility). This new script would provide standard command line flags like --help and --version, and would also provide an init command to generate a minimal config. This script would also need to take a command or flag indicating the mode (client or runner).

Regarding config, I could see getting by with defaults in many cases. You'll still need a config for specifying remote environments when using a cloud testing service. One option would be a combination of init to generate a default config, and having Intern assume a config will be in something like tests/intern (so you can get by without specifying it if you follow the convention).

[rodneyrehm]

while we're talking about the CLI, the following feature would help:

a way to simply have the intern proxy started and my browser open client.html with the given config. right now you have to run a separate HTTP server (e.g. http-server) to get access to your tests in a browser.

[sholladay]

Right, setup the browser client from the command line. I would :heart: that.

I don't use a separate web server, though. proxyOnly and localhost:9000/node_modules/intern/client.html works awesome for me.

[jason0x43]

So, you're just looking for an easy way to kick off the proxy and open a persistent browser session? Because intern-runner already runs unit tests in a browser (or browsers) from the command line...

[rodneyrehm]

So, you're just looking for an easy way to kick off the proxy and open a persistent browser session?

well, if you use open you're not really dealing with a browser, more telling the OS to open something in some application. So if I already have Chrome open and run open("http://www.google.com", "Google Chrome"); it will simply open that URL in a new tab in the foreground window.

Because intern-runner already runs unit tests in a browser (or browsers) from the command line...

The difference is that intern-runner talks to a WebDriver endpoint. As far as I know WebDriver and DevTools don't work well together. intern-runner is great for running the tests - as that's what it's made for - but not so much for debugging tests.

[sholladay]

Yeah, that would be more about improving the experience of the browser client and the use cases it already exists for. Basically making run.html unnecessary. The thing is, you already have to set up the server/proxy that hosts the client.html (and optionally the run.html) page(s) from the command line. Then you have to jump through some hoops to open the browser and navigate to the right place. Even staying on the command line with open /path/to/run.html is a pain, because intern-runner proxyOnly (and things like it) sit at the prompt without returning (unless you break out your bash skills).

A theoretical intern browser-client command would just do whatever necessary to open the browser client for you in one fell swoop.

[jason0x43]

There is now an official Intern CLI that provides help and an easy way to start the proxy for serving local browser tests (it'll even open your default browser). I'm going to close out this issue since at least its initial focus has been addressed (hopefully). Please raise any new CLI issues in the intern-cli project. Grunt-related things can stay here.