Instead depend on npm to dedupe. This is better as we will no longer fail if the user has Babel 6 and we Babel 5, and npm just won't dedupe. Same situation in the future when we're on Babel 6, but the user is still on Babel 5.
Use the source-map-fixtures package to provide a fixture which throws an error.
Stack traces should be corrected for this fixtures.
Add a script to generate a test fixture that comes with an input source map.
Errors from this fixture should be mapped to the input source. Having the script
makes it easier to update this fixture in the future.
The generated fixture now uses a source map file. Commenting out the
inputSourceMap code in lib/babel.js didn't cause the test to fail if an inline
source map was used. I'm not sure why that is. The test fails as expected when
using a map file.
Note that the original 'stack traces for exceptions are corrected using a source
map' test only tested the source map cached by lib/babel.js. This is already
covered by the new 'stack traces for exceptions are corrected using a source
map, taking an initial source map for the test file into account' test.
We throw the error from another fixture which uses a source map file. This
implicitly tests source-map-support. We're not testing a fixture which uses an
inline source map, firstly because that's somewhat superfluous and secondly
because the generated stack trace line is deemed not important due to the
logger's behavior and a source-map-support bug
(<https://github.com/evanw/node-source-map-support/pull/119>).
There were two problems with using destructuring on the `t` parameter
passed to tests:
1. `t.end` is enumerable, but throws when accessed. This created
problems when destructuring using rest params `{ok, ...t}`.
The solution: `t.end` is enumerable only in "callback mode".
2. `t._capt`, `t._expr` are not enumerable, and therefore not
exposed as a member of the `...t` rest param.
The only solution was to make them enumerable.
Not ideal, but better than the confusing error that previously occurred.
There are two possible errors that can result in no test data being
received.
1. The user never imports `ava` in their test file.
2. The user has not written any tests in the file yet.
We treat both as errors, but were handling them differently.
Most problematic, one caused the promise to resolve, the other
caused the promise to reject.
Nothing wrong with the implementation, but the test was only
checking test duration, not that the test passed. The test
was incorrecty using `t.end`, and so finished quicker than expected.