Use temporary test-only build of mocha.js for browsers tests

[Munter]

This PR does the following things:

• Creates a new BUILDTMP/mocha.js temporary file during test run, used by karma test only
• Deletes BUILDTMP after successful run
• Changed all make test run targets to depend on the new temporary file instead of an updated dist file
• Added BUILDTMP to all relevant ignore lists
• Added npm preversion hook to run tests and create the mocha.js distribution build artefact, plus stage it, so the build artifacts become a part of the release created by npm version

The overall goal of this PR is to only ever have the mocha.js browser build artefact generated when creating a new release. We want to avoid that contributors accidentally generate the build artefact during a normal test run and then accidentally check in the updated artefact.

[coveralls]

Changes Unknown when pulling 9a6a93b on avoid-dist-file-modification-in-test into ** on master**.

[c089]

👍 That changing mocha.js file confused me initially, so this should reduce barrier for new contributors.

What's the reason to use a fixed tmp dir in the repo instead of having one created in the OS tmp directory (e.g. using mktemp)? That way OS could take care of tmp cleanup and we wouldn't pollute the working copy.

[Munter]

mktemp is a unix-only tool. We eventually need windows support for everything. Debugging the build pipeline also becomes easier with human readable and accessible locations imo

[Munter]

Come on saucelabs! I've been restarting this job at least 5 times now :(

[c089]

oh, windows. I keep forgetting about that ;)

[ScottFreeCode]

In my mind, there are two reasons to use an OS-managed temp file location over a local one of some sort:

• The OS/sysadmin can clean up old files there without having to know about every project that's using temporary files.
• You avoid cluttering your local [project, documents, whatever it is] with temporary files.

The second reason doesn't apply if you put all the temp files in a local place specifically dedicated to temp files, or if you only have a small predefined set of files with reasonable names. The first reason doesn't apply if you've got a predefined set of files (so it's not going to keep eating up more space indefinitely if not cleaned up) and the local folder is inside the relevant project/system/whatever (so removing or uninstalling the thing will take its temp files with it).

In other words, to my knowledge there's no reason for Mocha to use the OS temp file system for this, regardless of feasibility.

Now, I can name some popular subsystems that have caches in dedicated, separate-from-the-subsystem yet subsystem-specific locations that I wish would use the OS temp directory instead, so that I don't have to remember to manage that subsystem's cache space. (Granted, there's a distinction between "temporary file" and "cache", but in either case they're supposed to be able to be cleaned out from time to time without affecting the correctness of the program -- and need to be if you don't have indefinite disc space to blow on it.) But that's quite a different situation! ;^)

[ScottFreeCode]

This looks good to me assuming it works.

[ScottFreeCode]

I think it's worth noting that this makes the directory quite obvious (not only is it not a dot-directory like .buildtmp, but it's in CAPs); I assume this is intentional?

[Munter]

On a successful test run the directory is cleaned out. This happens in the npm test script. Changing the directory name is a minor thing. I'm open to suggestions of something better

[coveralls]

Coverage remained the same at 76.779% when pulling 8a93a54 on avoid-dist-file-modification-in-test into 52a1957 on master.