Transpile in main thread

[jamestalmage]

Manual reimplementation of #349.

This moves Babel transforms to the main process, and caches the transpiled results.

It uses caching-transform to provide caching. Expensive requires (like babel) are placed inside the factory function, which caching-transform only calls when it determines it needs to transform a file.

The path to each precompiled test is passed in the options object to fork:

fork('/path/to/file.js', {
  precompiled: {
    '/path/to/file.js': '/path/to/cached/file.js'
  }
});

It uses require-precompiled to install a require hook that pulls the transformed file from the cache.

The caching directory is used by the users package.json, and installing in node_modules/.cache/ava.
If the cache directory cannot be found (i.e. if they have no package.json), or the user provides a --no-cache flag, pre-compilation still happens on the main thread - but results are published to a temp directory.

[jamestalmage]

Using got 6.0.0 branch:

master - first run (no cache)

./node_modules/.bin/ava  22.74s user 1.81s system 372% cpu 6.587 total

master - second run (with cache)

./node_modules/.bin/ava  6.65s user 0.77s system 175% cpu 4.240 total

this branch - first run (no cache)

./node_modules/.bin/ava  7.78s user 0.79s system 132% cpu 6.474 total

this branch - second run (w /cache)

./node_modules/.bin/ava  6.76s user 0.77s system 178% cpu 4.226 total

---

Huge advantage when the cache is empty.

[jamestalmage]

@sindresorhus, @vdemedes, et al. - ready for review.

[ariporad]

@jamestalmage: What we do everywhere else is just invoke ourself with new and return it. Maybe switch to that?:

if (!(this instanceof CachingPrecompiler)) {
    return new CachingPrecompiler(cacheDir);
}

[jamestalmage]

Yeah sure. Probably worth matching style.

That said, after doing it the way you suggest for a long time, I am starting to think it's a mistake. ES2015 classes throw when function called, so magic auto-newing is not future proof. Also, it introduces an easy to overlook failure point when refactoring the function signature. I know I have forgotten to update that statement inside the if condition before.

[sindresorhus]

I prefer being explicit and use new for classes. ES2015 seems to agree with me.

[jamestalmage]

OK, changed it back to the original behavior (throw if they forget to use new).

[ariporad]

@jamestalmage: Looks pretty good, expect for the few things I mentioned. Also, it looks like there aren't very many tests on the CachingPrecompiler itself (I don't know if there needs to be).

[sindresorhus]

Make sure to include the babelrc: false thing here.

[sindresorhus]

Woo, nice improvement on cold start! 👍

Generally looks good to me. Could use a test though.

@vdemedes ?

[jamestalmage]

could use a test though.

Yeah. How far do you want me to take it? For nyc, we run every test twice (once with caching on, once with caching off). That was easy to pull off with nyc due to how we build our test suite.

This is what I am thinking for tests:

1. Test a fixture project with caching on. Once the test completes ensure there are X number of files in the cache directory.
2. Delete the cache and test the same fixture from 1 again. Ensure the cache stays empty.
3. Duplicate some of our source map tests with caching off? I might need @novemberborn's help here since I know next to zero about how a good source map test should look.

[sindresorhus]

I don't think we should run all tests with and without. Just need some integration tests to ensure it's working correctly. What you've proposed sounds fine.

[vadimdemedes]

I'd use isCacheEnabled, something more verbose & logical given the boolean variable value.

[jamestalmage]

How about just cacheEnabled?

[vadimdemedes]

Or that, yeah

[vadimdemedes]

I really dig the perf improvement! I commented on a few things, but never mind. We can do a cleanup later, I'd rather have this PR merged ASAP.

[jamestalmage]

OK, Incorporated the last round of feedback from @vdemedes. Once CI passes again, I intend to merge.