1

This might be a bug in Babel CLI (I'm using 6.24.1), but it appears that Babel doesn't apply .babelrc when the source data is being piped to it.

Example:

Given this source file, foo.js:

const foo = 10;

Good: This command does what you think it should, with a .babelrc in the same directory with the es2015 preset in it:

babel foo.js --out-file foo.classic.js

This results in foo.classic.js, with properly transpiled content:

"use strict";

var foo = 10;

Bad: This command does not do what you expect:

cat foo.js | babel --out-file foo2.classic.js

This results in foo2.classic.js, with unchanged content:

const foo = 10;

Good: This command does what you expect, so it's not the actual configuration at fault:

cat foo.js | babel --presets es2015 --out-file foo3.classic.js

Result in foo3.classic.js:

"use strict";

var foo = 10;

Analysis: In the piping cases, Babel is obviously reading the data from the pipe and passing it out (because the output file gets created), but it appears that Babel completely ignores the .babelrc when it gets the data from the pipe.

For reference, this is the .babelrc that is supposed to be applied:

{
    "presets": [ "es2015" ]
}

Why use pipes?

For what it's worth, you might wonder, "Why pipe input to Babel? Why not just use files?"

Well, for one thing, piping is a supported feature, so it should "just work."

But in my case, the source files being passed to Babel are themselves the result of a code-generation chain that produces valid ES6 code as output. It would be nice not to have to have the code generator output a ~temp.js intermediate file and then have to have it be deleted afterward; it would be far better if the pipes just worked as they're supposed to.

The Question:

Is this a bug? If it is, does anyone know of a better workaround than just emitting a file named ~temp.js, passing that to Babel, and then deleting it?

Sean Werkema
  • 5,810
  • 2
  • 38
  • 42
  • How about `babel --out-file foo2.classic.js < foo.js`? – Andrew Li Jun 07 '17 at 12:59
  • If that worked (which it doesn't), it would only be suitable if the source is a `.js` file, and it is not: As I said, the JavaScript comes from the `stdout` of another code-generator. But since `<` produces the same output as the `cat |` version, it's a moot point. – Sean Werkema Jun 07 '17 at 13:05

1 Answers1

1

This is currently expected behavior, but we've talked about some alternatives in https://github.com/babel/babel/pull/5384.

See my comment here for some info. As mentioned in there, the current fix for you would be to do

cat foo.js | babel --filename foo.js --out-file foo2.classic.js

to tell Babel the filename, so it knows where to search for the .babelrc file.

loganfsmyth
  • 156,129
  • 30
  • 331
  • 251
  • Well, a little disappointing, but the accepted answer, since it's from an official maintainer. I'm definitely in agreement, though, with `kirs`'s suggestion there to add a `--babelrc` option. It's not complicated to understand (or to implement), is similar to the `--config` options many other tools have (so there's precedent), and it's very predictable in its behavior. – Sean Werkema Jun 07 '17 at 17:18
  • `kirs` is definitely right about one thing, though: Current behavior absolutely violates the Principle of Least Astonishment, so that alone calls for some kind of change. Either it should read from current directory or add `--babelrc` (or, better yet, do both) to support interaction with `stdin`. – Sean Werkema Jun 07 '17 at 17:25
  • 1
    Yeah I agree the current behavior isn't clear or obvious to people. – loganfsmyth Jun 07 '17 at 17:54