Disable babel via --no-babel flag

[pablodenadai]

I'm wondering if it's possible to disable Babel "transpilation" phase when I run AVA.

I'm using Node 5.x which already has all ES6 features that I need to use.

[vadimdemedes]

Nope, not at the moment. I was also wondering whether we should have an ability to turn off babel. I think we should leave it as a feature request.

[pablodenadai]

Cool, thanks for the reply @vdemedes.

The test below would break when using Babel.

const favorite = 7;
try {
favorite = 15;
} catch (err) {
t.is(favorite, 7);
}
//=> Error: "favorite" is read-only.

Updated:

const favorite = 7;
favorite = 15;
t.is(favorite, 7);
//=> Error: "favorite" is read-only.

[sindresorhus]

@ghpabs That is invalid. Use let if you want to reassign the variable. Nothing to do with Babel.

[pablodenadai]

Hi @sindresorhus, I don't believe it's invalid JS - at least not in Node from what I can see.

Try running the following code in the Node REPL.

const foo = 7;
foo = 15;
console.log(foo);
//=> 7;

No errors were thrown.

Ps. Maybe this piece of code is only adding complexity to the issue. The original intent for this ticket was the question around disabling Babel.

Thanks!

Edit: Node v5.3.0

[sindresorhus]

It's true that it works in sloppy mode (which the REPL is running in), but you should really not depend on that. It's the wrong use of const and it's not future proof. It will not work in strict mode or ES2015 modules, which implicitly run in strict mode.

❯ node -e "'use strict';const foo = 7;foo = 15;console.log(foo);"
[eval]:1
'use strict';const foo = 7;foo = 15;console.log(foo);
                               ^

TypeError: Assignment to constant variable.

The whole point of const is creating an immutable binding. If you want const with mutable binding it's pretty much exactly let.

Not derailing this issue. We'll consider you request. Just wanted to point it out to you.

[pablodenadai]

Great, thanks for taking the time to explain it. Love your work.

[jamestalmage]

We've talked it over and decided that a --no-babel flag is an acceptable (if possibly temporary) fix. It's going to slow things down a lot. Especially for npm@2 users. Any PR should include documentation warning that npm@3 is highly recommended with that flag.

[ariporad]

@jamestalmage: I'll take that on, I need something to do on the plane
tomorrow.
On Fri, Jan 15, 2016 at 2:04 PM James Talmage [email protected]
wrote:

We've talked it over and decided that a --no-babel flag is an acceptable
(if possibly temporary) fix. It's going to slow things down a lot.
Especially for npm@2 users. Any PR should include documentation warning
that npm@3 is highly recommended with that flag.

—
Reply to this email directly or view it on GitHub
#424 (comment).

[jamestalmage]

@ariporad 👍 I thought you might 😄

[pablodenadai]

Any updates on this one @ariporad?

[novemberborn]

#448 should let you specify an empty babel config. If I'm not mistaken this makes Babel a no-op, achieving the same as a --no-babel flag.

@sindresorhus I suppose we could close this in favor of #448? Could make a new issue for documentation purposes.

[sindresorhus]

Yes, let's close it in favor of #448 (comment), which should handle that.