Disable Babel

[sebmck]

Is there a way to disable Babel transforming test files? I'm trying to use ava for Babel core and I'm running into issues getting it to work because Babel links up all it's dependencies and ava is resolving babel-core to my 6.0 master development version. Happy to submit a PR if necessary!

[sindresorhus]

It might work if you depend on the tagged git version of Babel 5 locally as AVA will use that one instead of the builtin one. I use that trick in XO to be able to lint itself: https://github.com/sindresorhus/xo/blob/dd233cc40a1984a793000f260062c520767a685b/package.json#L78

If that doesn't work, I guess we could add a flag, but I was hoping we didn't have to, as there's no other reason I can think of to disable Babel.

[Lalem001]

Hello @sindresorhus, I have a case you may wish to consider.

I am looking to use AVA to test a node ^4.2.0 app that uses the built in ES6 features without babel.

Is this a case you would be willing to support?

[jamestalmage]

@Lalem001

By default, AVA will only instrument your tests, not production code. There is no good reason not to take advantage of Babel instrumentation in your tests.

[sindresorhus]

I am looking to use AVA to test a node ^4.2.0 app that uses the built in ES6 features without babel.

Node.js 4.2.0 is missing a lot of ES2015 features. Also nice being able to use ES2016 features like async functions. Disabling Babel will not only disable Babel, but also the enhanced asserts. I plan on looking into creating Node.js version specific presets, so it only transpiles what's not supported natively. This became a lot easier to achieve with Babel 6.

[jamestalmage]

I plan on looking into creating Node.js version specific presets, so it only transpiles what's not supported natively.

That was on my radar as well. Lets not duplicate effort.

[sindresorhus]

@jamestalmage Yeah, only an idea yet. Feel free to take it on. Let's continue this in #148.

[schnittstabil]

By default, AVA will only instrument your tests, not production code.

That seems to be true, but Babel polyfills are also available in production code, making AVA almost unusable for testing polyfills:

// sut.js
module.exports = function () {
    return !!Object.getOwnPropertySymbols;
};

// test.js
import test from 'ava';
import sut from './sut'

test(t => {
  t.true(sut());
  t.end();
});

$ node --version
v0.10.40

$ node -e 'console.log(!!Object.getOwnPropertySymbols)'
false

$ ava
  ✔ [anonymous]

  1 test passed

Or is this a bug?

[jamestalmage]

Ah - that is a good point. Not sure if @1d5ef4c5f6fcb70f9e90e584dfd08865db1e93b4 (landed in master, but not published) will address that.

[floatdrop]

@jamestalmage yep, thats what that fix was for, it still need some work thou (#150).

[jamestalmage]

Instead of "Disable Babel", How about an option to disable the lookup of the local version, and force ava to use whichever version it shipped with.

[novemberborn]

Instead of "Disable Babel", How about an option to disable the lookup of the local version, and force ava to use whichever version it shipped with.

#390 takes care of this. Closing.

[callumlocke]

So what's the correct way to completely disable Babel compilation (for when I know my test scripts only use syntax that is 100% supported by my target Node version)?

"ava": { "babel": false } causes a fatal error in ava v0.14 for me.

[novemberborn]

@callumlocke try with "ava": { "babel": {} }. That prevents AVA from applying the default presets. It will still run Babel though, as it needs to add power-assert transforms and some other helpers.

[jamestalmage]

We should probably alias babel:false to babel: {}.

[Lalem001]

Trying "ava": { "babel": {} } gave me the following error (shortened for clarity)

import _Promise from 'project/node_modules/ava/node_modules/babel-runtime/core-js/promise.js';
^^^^^^

SyntaxError: Unexpected reserved word

This is on Node@4.4.2, npm@2.15.1, and ava@0.14.0.

Let me know if you would like the full log.

[jamestalmage]

Try adding just this plugin: http://babeljs.io/docs/plugins/transform-es2015-modules-commonjs/

[Lalem001]

@jamestalmage That fixed it. However the suggestion requires adding a new devDependency on a project that otherwise has no need for babel.

It would be nice if we could use that plugin directly from ava's own dependency on babel-preset-es2015 which in turn depends on the transform plugin. May be possible with npm@3.

Not a call to action, just sharing thoughts.

[jamestalmage]

the suggestion requires adding a new devDependency on a project that otherwise has no need for babel

I'm just curious, what motivates the "no babel" decision. Missing out on async/await for your tests seems like a really big deal to me.

To answer your question, it is unlikely we are going to alter the lookup paths for the presets again (we used to, and it was problematic). npm@3 is the solution here.

[Lalem001]

For me, at the time I originally posted in this thread, the "no babel" idea was purely in the interest of reducing the time it takes to test.

[novemberborn]

However the suggestion requires adding a new devDependency on a project that otherwise has no need for babel.

You could use CJS' require() rather than import.

For me, at the time I originally posted in this thread, the "no babel" idea was purely in the interest of reducing the time it takes to test.

AVA will still apply a Babel transform, I doubt disabling the default presets will dramatically speed up your tests.

[callumlocke]

@jamestalmage:

I'm just curious, what motivates the "no babel" decision. Missing out on async/await for your tests seems like a really big deal to me.

For me, it's because I put all my app code and tests through a single compilation step before I run my tests. So I don't miss out on async/await, or anything else from ESNext. I just put everything (both lib and test) into a root folder called src, and continuously compile this whole folder to dist. Separately, I run AVA against dist/test. Here's an example using Babel and AVA separately in this way.

Personally I don't want my test runner / assertion library (AVA) to concern itself with on-the-fly compilation; it's too many things in one tool. I don't think Babel is really stable enough to use transparently like that. Babel is a great tool, but imo it's better done as a distinct build step, not magically at runtime/testtime. This way, all your compiled code exists as real files on disk (not just fleeting ideas in RAM) that can run directly in your target runtime, and which you can debug directly without relying on sourcemaps (also flakey). I've had way fewer problems since switching to this approach.

[paulmillr]

My five cents here: the traces are pretty bad when using babel in some cases.

[novemberborn]

@paulmillr could you elaborate?

[sindresorhus]

@callumlocke We're not just using Babel for the syntax. Babel enables power-assert, detecting incorrect use of t.throws (very common mistake), and more. And we plan on using it for many more things in the future.