[0.16.0-rc] using a library which uses a .babelrc is broken

[gre]

I'm developing a library that have a .babelrc and exposed both for web and native.

it contains:

{
  "presets": ["es2015", "stage-1", "react"]
}

I've creating an empty RN 0.16.0-rc project, add my lib in dependencies, and when trying to run, it breaks:

it still breaks the same if I just have ["es2015"].

Each library should be able to expose a .babelrc right? I thought this was the convention.

[ide]

The tentative solution was to get library authors to omit .babelrc from npm packages but I'm finding that's not a scalable solution. In our fork of RN we disable babelrc support across the board.

cc @sebmck

[satya164]

Duplicate of #4062

[adriansdev]

This is affecting the 'alt' framework. Removing .babelrc works goatslacker/alt#558

[atticoos]

I've been running into this all over the place with Redux.

@NullDivision suggests removing the babel executable from ./node_modules/.bin so you can fallback to your global executable that you can run at version 5 of Babel.

Not an ideal workaround, but it can get things working again for the time being.

Ref reduxjs/react-redux#206 (comment)

[skevy]

I've been deep in the packager code lately...if I get a chance today maybe I'll take a look at how to ignore .babelrc's.

[gre]

Thanks. BTW I've taken the path of writing a prepublish script ( https://github.com/ProjectSeptemberInc/gl-react/blob/master/package.json#L5-L9 ) to publish a "compiled" lib to NPM.

I think it's also safer (instead of publishing ES6+ / JSX code that might not work for everyone), more compatible with whatever the build tool is (browserify / webpack / RN packager) and also take less compilation time ;)

so anyway, let's stick with #4062 more general discussion. closing this issue.