Closed rightaway closed 8 years ago
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.
I also think the CLI ought to get a makeover. Even --version
doesn't work.
I agree, the command line interface could use some love.
Going to collect some thoughts on the CLI here. Happy to file separate tickets if its helpful.
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.--version
, --help
don't exist.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 aboutinit
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.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).
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.
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.
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...
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.
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.
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.
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: