Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate instantiating new API and reporter in --watch #533

Closed
novemberborn opened this issue Feb 9, 2016 · 8 comments
Closed

Investigate instantiating new API and reporter in --watch #533

novemberborn opened this issue Feb 9, 2016 · 8 comments
Labels

Comments

@novemberborn
Copy link
Member

#502 resets the API and logger/reporter between runs. Creating fresh instances may be preferable. This would require some sort of code sharing between cli.js and watcher.js though, since the former sets up the instances and has access to the required CLI flags.

One option would be to pass a callback to watcher.start() allowing the watcher to create new API and logger/reporter instances, but leaving the definition in cli.js.

@novemberborn
Copy link
Member Author

@jamestalmage given your refactoring work what's your take on this?

@jamestalmage
Copy link
Contributor

I actually was thinking we could move watcher support into the API itself. That was kind of the thinking behind the test-run event. Also, in my refactor branch lib/ava-files could probably incorporate some of the file-path processing in watcher.js (I'm thinking methods like makeTestMatcher and buildChokidarPatterns, etc).

I'm thinking of adapting the run method a little:

// new testRun is returned immediately, it may not start receiving events until the current run finishes.

var testRun = api.run(files, {
  runOnlyExclusive: boolean,
  stopCurrentRun: boolean
});

testRun.on('test', ...)

testRun.result.then(function (result) {

});

@sindresorhus
Copy link
Member

I like that idea. Ideally the CLI should just be a tiny wrapper around the API, with CLI only stuff.

@jamestalmage
Copy link
Contributor

Ideally the CLI should just be a tiny wrapper around the API, with CLI only stuff.

Agreed. Our CLI is pretty huge. A lot of it is options processing (parsing the command line and merging with package.json). Part of the idea behind #700 is to reduce the amount of options processing API consumers would need to do.

@novemberborn
Copy link
Member Author

I actually was thinking we could move watcher support into the API itself.

The watcher is fairly big though. I wonder if we could make the watcher instantiate its Api. We couldn't before due to how the loggers were coupled.

@jamestalmage
Copy link
Contributor

I didn't mean "move all of watcher.js into api.js". Just expose a way to pass options {watch: true} to the API and receive test-run events as files change.

@novemberborn
Copy link
Member Author

@jamestalmage that sound cool.

@novemberborn
Copy link
Member Author

The lack of this refactor hasn't been an issue. Closing this, but I expect we'll do something like this eventually as needs dictate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants