babelrc is not read when using babelify

[kirbysayshi]

It appears that something is preventing babel from reading in the local .babelrc when running via babelify. Here is a gist that demonstrates the problem: https://gist.github.com/kirbysayshi/c0df1bf8bbbac53d0c1c

$ git clone https://gist.github.com/kirbysayshi/c0df1bf8bbbac53d0c1c babelify-test && cd babelify-test
$ npm install
...
$ npm run js
> babelify-test@0.0.0 js /private/tmp/babelify-test
> browserify index.js -o bundle.js


/private/tmp/babelify-test/index.js:1
import Promise from 'es6-promise';
^
ParseError: 'import' and 'export' may appear only with 'sourceType: module'

If I place the presets key within the package.json browserify config, then the code compiles just fine. I believe this worked before babel 6, so perhaps it's an upstream bug. Not sure.

[kirbysayshi]

Further investigation reveals that when I supply babelify as a transform, but do not specify any options for it, then babelrc is read correctly.

So this reads in babelrc:

  "browserify": {
    "transform": [
      [
        "babelify"
      ],
      "envify"
    ]
  },

This does not:

  "browserify": {
    "transform": [
      [
        "babelify",
        {
          "sourceMapRelative": "true"
        }
      ],
      "envify"
    ]
  },

I believe the expected behavior is that the options are merged, especially if no babel-specific options are provided via transform config. Or am I misinterpreting?

[zertosh]

Yeah, it's a bug with sourceMapRelative – setting it breaks the babelrc. FYI, the way sourcemaps are handled now, sourceMapRelative doesn't work. You can use sourceRoot to get the same effect, or give browserify a basedir. If you look through the source maps tests, you can see the different approaches. I haven't had time to dig into it much and write better docs. Sorry.

[callumlocke]

Does that mean babelrc is supposed to work (pending bugfixes)? If so it would be good to mention that in the readme

[zertosh]

babelrc works. it's sourceMapRelative that doesn't. just remove that.

[callumlocke]

in that case can the readme be updated to mention that babel config is read automatically from .babelrc and package.json (?) as usual with babel, and if you want to manually override it at runtime you can also do that? currently it only mentions the manual runtime override technique, implying that's the preferred/only way to configure babelify.

[zertosh]

sure? It is ambiguous somewhere that normal babel behavior doesn't apply when using babelify?

[jmm]

I think it's a bit surprising for a browserify transform to read options from the file system (not counting browserify.transform in package.json). Do any others do that? Also, it isn't even documented for Babel that it'll read options from the file system when calling .transform() with an absolute filename opt: babel/website#539.

[callumlocke]

I don't think it's obvious babelify would look for babelrc. Not so obvious it doesn't need mentioning, anyway. Especially as there's a big section about different browserify-specific ways to configure it, but there's no mention that the standard Babel way works fine too.

[kirbysayshi]

@zertosh thanks for the tip regarding sourceMapRelative. Removing that worked!

I agree it's not obvious that babelify (via babel) reads babelrc, since most libraries in my experience don't read configuration from the file system unless it's run as a command line tool. In this case, I'm very glad babelify and babel behave this way, because it allows for my configuration to exist in only one place. Especially for things like npm scripts and node-babel.

Thanks for responding so quickly!

[queckezz]

Awesome, was looking for that. Is it somehow possible to change the name from .babelrc to something like babel.json? In babel CLI theres a option called --babelrc babel.json which you can use. This doesn't work with babelify.

[zertosh]

@queckezz Any option that you pass babelify gets passed to babel. So if that's a CLI only option, then it won't work. I didn't know that option existed, nor do I see it in the CLI package.

[queckezz]

@zertosh Right, thanks! I'm sorry for the noise. The option --babelrc was actually pre babel@6 and it seems like they've stopped supporting it.