Deprecate --watch

[jbnicolai]

@boneskull commented on Jan 30

IMO "watch" should be killed. There are other tools which do this sort of thing much better.

@dasilvacontin commented on Jan 31

+1 to kill watch. I don't see the point of replicating the functionality of a watcher inside the project, when any watcher tool will do the job.

Creating a separate issue for this, so we can close the unrelated #871

[boneskull]

yes please

[jprichardson]

Agreed. I'd really like see Mocha v3 broken down into smaller modules with a lean core.

[ELLIOTTCABLE]

It'd be nice to see some suggestions on an alternative, then; all of the 👍'ers obviously know of a better replacement, but I, personally, do not. (I suspect the same is true of plenty of users. :P)

[danielstjules]

It'd be nice to see some suggestions on an alternative

https://github.com/gruntjs/grunt-contrib-watch
https://github.com/floatdrop/gulp-watch

I definitely still use --watch for some projects, as not all need a task runner. But its absence from the core wouldn't be missed if a plugin system exists. Or if everyone just uses a task runner.

[markelog]

Not everyone use grunt/gulp tasks for that sort of thing, some ppl like to use npm scripts for it.

This is also pretty useful with compilers flag. Yeah, you can use something like:
forever start -c "mocha /path" /path. But it seems much more complicated then it should be.

[boneskull]

"do one thing and do it well"

Mocha runs tests well. It doesn't watch files well. There are better solutions. I understand it is handy for some people, but it's out of scope.

[markelog]

What is the alternative?

[boneskull]

read above

[markelog]

Would you mind reading my comment too please?

[boneskull]

I did. But whether or not you use a task runner, forever, fswatch or whatever is your choice.

[markelog]

I'm not sure if forever start -c "mocha /path" /path would work, didn't start for me, not sure it even if it should.

If you removing this feature, would you mind providing the other clear path to do it?

[boneskull]

gaze is probably going to be your best bet

[boneskull]

if you don't need something node-based, gaze is a wrapper around the excellent fswatch

[boneskull]

many IDEs and text editors also have this functionality built-in

[markelog]

fswatch couldn't be added as node dependency, gaze doesn't have a CLI api. Including prerequisite for projects to use some IDE seems...

Okay, in other words, i either need to switch my projects on some task manager or i can still use mocha but only through programmatic API with some watcher.

That is a bad move in my opinion.

[boneskull]

re: fswatch "if you don't need something node-based" ... it's not a node package. apt-get install fswatch or brew install fswatch or whathaveyou.

I'm not sure why I need to do this for you, but here's a CLI for gaze.

[markelog]

re: fswatch "if you don't need something node-based" ... it's not a node package. apt-get install fswatch or brew install fswatch or whathaveyou.

Yes, that is why i said "fswatch couldn't be added as node dependency", it is like asking people to install debian package to run mocha.

here's a CLI for gaze.

That is the same thing as forever start -c "mocha /path" /path, see above as they say :-), this is less cool and you couldn't put it in mocha.opts, if you use compiler flag, things get even worse. But okay, that would do.

I'm not sure why I need to do this for you

Usually, when maintainers of some package, remove pre-existing functionality, they provide an explanation of why they do it and provide an alternative way to achieve the goal.

Explanation is the necessity, alternative way, is a common courtesy, sign of mutual respect, not a favor.

In other words you don't "need" to do anything and i'm sorry i "need" to write this.

[boneskull]

Yes, that is why i said "fswatch couldn't be added as node dependency", it is like asking people to install debian package to run mocha.

Yes. Though, gaze is a wrapper around fswatch. When you install it, it compiles fswatch for you. There are many, many NodeJS wrappers around non-NodeJS projects. And some that just expect the executable to be there. For instance, how would you run npm without git installed? So, in my mind, not a huge deal, and a viable alternative.

Explanation is the necessity, alternative way, is a common courtesy, sign of mutual respect, not a favor.

When support is dropped the responsible thing would be to explain a viable alternative--and we will!

My comment was out of frustration; obviously there are viable alternatives, and I know you know that. I felt I had to "google it" for you. This was not meant to be disrespectful and I apologize if it came across that way.

I use grunt-contrib-watch if I need a watcher in all of my projects. Most of the time I don't, because my IDE does it for me. This solution works for me.

We'll provide well-documented alternatives when the time comes, so thank you for reminding me. In fact, it may be worthwhile to add a "pending deprecation" notice when --watch is used.

[ELLIOTTCABLE]

It wouldn't be necessary to ‘google it’ for us, except that's precisely what I asked you to do. @markelog was just clarifying my request, I believe.

As for why I asked: I'm not curious about what the solutions are (I'm not a beginner. I do, in fact, know how to use a search engine.); I'm asking what Mocha's response to that question will be, when this is deprecated. I'm sorry I didn't word that better.

If gaze-cli will be the suggested go-to for confused users (read again, because apparently I need to specify this: not me.), I still think @markelog has a valid concern, although it's a rather small one in the grand scheme of things: mocha --watch widget is substantially D.R.Y.'er and more approachable than gaze "mocha widget" widget, or so on and so forth.

Personally, I don't think that's a blocking problem re: deprecating this. I'm all for doing so. ¯_(ツ)_/¯

[boneskull]

@ELLIOTTCABLE @markelog Maybe this.

[ELLIOTTCABLE]

Since gaze is now apparently abandonware, and most of the large projects (Gulp, browserify, Karma) have switched over to Chokidar, may I suggest chokidar-cli?

In addition to the wider support, it solves the one concern I had above, by providing {path} substitution, letting us D.R.Y. up the Mocha command:

chokidar 'tests/*.js' -c 'mocha "{path}"'

[Vanuan]

I use https://github.com/testem/testem for this.

[boneskull]

@ELLIOTTCABLE Yes, chokidar is the way to go

[padcom]

-1 for this. I like every bit of the --watch how easy it is to setup and how it fits within my package.json/scripts section. Please don't kill it!!!

[boneskull]

@padcom Mocha's main responsibility isn't watching files. We frequently get many issues around the watch functionality, because it doesn't work how people think it will, or has bugs in edge cases, or isn't working cross-platform. To that end, it should be removed from "core". The functionality is helpful, but it's better handled by a third-party tool.

That said, there are certain use cases that likely won't work "out-of-the-box" with a third-party tool. A separate module which would wrap something like chokidar is in order. mowatch is/was an experimental tool to provide this outside of Mocha's core. It doesn't use chokidar, but it should.

[Vanuan]

Moreover, I find chokidar to be annoying (generates npm warnings on every npm install due to npm not supporting multiple platforms). So I would always prefer watcher to be a separate platform-specific tool rather than integrated into a test runner.

[djanowski]

All the proposed alternatives here seem to ignore the main point: Mocha's --watch is so useful because the Node process running the tests is kept alive.

If you have a very small project with very few dependencies and you're not doing transpilation, then you don't even need a Node tool to watch files and run a shell command. That's already invented and works well: http://entrproject.org.

Those of us who have somewhat bigger projects, using Babel transpilation, will need to find an alternative. A real one. That is, one that keeps Mocha running and doesn't have to respawn a Node process with everything that entails.

[mweststrate]

+1 on keeping --watch for the earlier mentioned reasons. Preferably, options like compilers and watch should become part of the Mocha library itself, as it now introduces unnecessary complexity on wrapper tools that want to support these same features. See this thread.

[ScottFreeCode]

I have a slightly different take on that: if the difference between Mocha's CLI and its JS API is preventing wrapper tools from being effective, we should reduce those differences in general so that wrapper tools will work right, including a dedicated watcher wrapper instead of counting watching as among the things that need to be pushed into the library.

I have a similar take on the problem of load times: Mocha's JS API needs better support for running more than once anyway, among other issues, and if we got such improvements then a dedicated watcher tool should be able to use the JS API to avoid total reloading.

Ultimately, I'd argue that --watch is a band-aid for the fact that other issues with programmatic usage of Mocha are getting in the way of using proper watcher tools with it, and those issues need to be fixed sooner or later regardless.

(For context, I don't feel like --watch needs to be eliminated right away, but I do think that ultimately we want to be in a position where dedicated watcher tools are the obvious way to go. That means, in the nearer term, addressing problems that wrapper tools have.)

[FullStackForger]

I do agree with @padcom (that argument is super important)

-1 for this. I like every bit of the --watch how easy it is to setup and how it fits within my package.json/scripts section. Please don't kill it!!!

Couldn't agree more with @ScottFreeCode as well. Until we find an good solution allowing to run mocha more than once especially with transpiler, we should keep --watch

I am repeating myself but consider this.

watch-run -i -p 'src/**/*' npm test:mocha

It works just fine, however it takes more and more time to execute as the code base grows. Reason? Using transpiler.

 "test:mocha": "mocha ./internals/test.setup.js ./src/**/*.spec.js* --require babel-core/register", 

Every time file changes mocha requires babel-register. That means eating away time to transpile everything, whereas re-running mocha tests with mocha --watch take a bit of initial time to kick in but once up and running it is super fast.

[ScottFreeCode]

Interesting bit of trivia (or, perhaps, an example of prioritization and things that go slow): in researching another issue, I discovered that --watch has been unpreferred since back in 2013: #909 (comment)

[ShiMeiWo]

I've read /bin/_mocha.js and got wondered a little about --watch.

var watchFiles = utils.files(cwd, [ 'js' ].concat(program.watchExtensions));

When we execute mocha-cli with --watch at workspace, the watchFiles contains whole files under workspace. So I tried edit _mocha.js manually like this and "Test-Runs-Twice Problem" seemed to be suppressed.

for example…

_mocha.js:

  //var watchFiles = utils.files(cwd, [ 'js' ].concat(program.watchExtensions));
  var ext = ['js'].concat(program.watchExtensions);
  var watchFiles = [];
  watchFiles = program.args.map(function(t) {
    return utils.files(resolve(t), ext)[0];
  });
  watchFiles = watchFiles.concat(utils.files(resolve('my/source/code/directory/'), ext));

command line:
 mocha -S -w  ./test/**/*

It might be a clue to resolve some problems about --watch.

[boneskull]

I'm going to close this since it's clear that enough people use --watch that it'll be extremely disruptive.

It really needs an overhaul though.