Disabling Babel

[jamestalmage]

The ability to disable Babel was brought up in #448, but completely disabling is problematic.

In addition to power-assert support, we use Babel for:

• Rewriting paths to babel-runtime. This isn't a big deal for people not using babel, but if the intent was to handle Babel processing out of band (via gulp or something), then there is still a potential for babel-runtime problems. Really, at that point the user should be required to add babel-runtime as a direct dependency anyways. So I think this one is kind of a non issue.
• (future) Static analysis for .only calls. In order to detect .only calls, I have been developing the ava-test-data plugin. The reasons we need to do this are described in Implement static analysis of test files (Blocker for #78). #696.
• (future) Static analysis of dependencies. By statically analyzing dependencies, we could precompile them in the main thread. See Transpile source files in the main process #577. The detective plugin is ready to do this. We already use it for the babel-runtime rewriting described above.

Given the complications with disabling Babel completely, I think we should table this for now (mark low-priority). If / when we eventually add the ability to use pluggable transforms in the main process(TypeScript, etc), we could possibly allow such plugins to provide the required features themselves.

[floatdrop]

I would like to bring it up with recent releases of Node.JS – what would ava miss without babel besides async/await (which can be transpiled with async-to-gen) and import? Babel taking considerable amount of time to install and run.

[vadimdemedes]

AVA still has to be compatible with Node.js v4 and it also uses Babel for power-assert and t.throws() helper.

[novemberborn]

We should support "babel": false. See also discussion around #1488 (comment).

[Siilwyn]

Just wanted to throw this in, Ava including babel is only annoying from Node 8 and up. It might be worth to consider dropping Node 4 & 6 once Ava 1.0 is released. Or releasing 1.0 (with babel) and some time after releasing 2.0 (dropping babel) backporting important changes.

[sindresorhus]

@Siilwyn If you had said Node.js 8, I would have agreed. The main reason we added Babel in the first place was to get async/await (which is part of Node.js 8) early.

[Siilwyn]

@sindresorhus whoops, you're completely right. I mixed up the version numbers. Fixed the comment.

[cjthompson]

I just installed ava to a blank repo and it installed 498 packages totaling 34M. I think babel should be removed as a dependency but supported as an option if the project is already using it.

[yamsellem]

Our biggest issue with Babel is that it mess with the debugger — visual code debugging hardly work with it.

I don't understand the use nor the interest of Babel when writing tests for nodejs. Since 4.x, nodejs widely supports JavaScript. So bringing source maps, transpiling and all the fuss server side is more complexity for a little gain (or not at all).

The tooling around ava is still very poor (no atom / visual code integration, no debugging), and this have way more value than ESnext features, IMO.

@sindresorhus I may understand the need for you guys, as ava developers (for async/await) but, why forcing the tests to be run with Babel? May you consider removing Babel for node >= 8.0 — now that async/await is part of it?

[sindresorhus]

I don't understand the use nor the interest of Babel when writing tests for nodejs.

Babel was added to AVA long before Node.js 4 and before ES2015 was fully implemented in Node.js. There's usually a reason things are like they are.

Since 4.x, nodejs widely supports JavaScript.

Node.js has always supported JavaScript, but I assume you meant ES2015. The thing is that JS is constantly evolving and there will always be features that are not yet implemented in V8. There are lots of interesting proposals for future JS features: https://github.com/tc39/proposals So Babel will always be needed if you want the absolute latest features.

The tooling around ava is still very poor (no atom / visual code integration, no debugging)

Help improve it then. I don't use either Atom or VS Code.

I may understand the need for you guys, as ava developers (for async/await) but, why forcing the tests to be run with Babel? May you consider removing Babel for node >= 8.0 — now that async/await is part of it?

Yes, we're open to it. It's just waiting for someone to implement it: #1556

[novemberborn]

Closing in favor of #1556.

[Siilwyn]

Oh that's a bummer. :/

[novemberborn]

@Siilwyn no it's not! Here's a test I'm writing right now:

test(`${prefix} babelConfig=false and compileEnhancements=false skips test file compilation`, t => {

[Siilwyn]

@novemberborn ah my main motivation is making the install size smaller but after reading the issue fully I see it makes Babel an optional dependency, which is great!

[novemberborn]

@Siilwyn we're keeping Babel as an actual dependency for now, actually.