[Discussion] Upgrade to Babel 6 breaks parts of the package ecosystem #4062

ide opened this Issue Nov 11, 2015 · 20 comments


None yet
ide commented Nov 11, 2015

With the upgrade to Babel 6, two things changed:

  • Babel or the packager appears to be looking at .babelrc in each npm package. When libraries like Redux publish a .babelrc for Babel 5 (ex: with the "stage" field), Babel 6 throws a TransformError.
  • Babel appears to not apply the .babelrc of the project root to each npm package, even if they don't contain .babelrc files

Before, you could configure .babelrc in your project root and Babel would compute something like the union of .babelrc + the options passed to transform(), and it would apply all those options to everything under node_modules. But now it seems not to apply the options specified in .babelrc to each npm package, so perhaps each package needs to ship with its own .babelrc and list its plugins in the package.json dependencies.

cc @sebmck you're probably the best person to comment on the state of things

kittens commented Nov 11, 2015

Babel or the packager appears to be looking at .babelrc in each npm package. When libraries like Redux publish a .babelrc for Babel 5 (ex: with the "stage" field), Babel 6 throws a TransformError.

Probably no way around this besides to get those packages to add .babelrc to their .npmignore.

Babel appears to not apply the .babelrc of the project root to each npm package, even if they don't contain .babelrc files

There's a bug in the latest version where it'll stop looking for parent .babelrc files if it finds a package.json. It'll be fixed in the next patch.

ide commented Nov 11, 2015

Awesome. Thanks for the clarification. I'll open up issues on the various affected repos to stop publishing .babelrc, and will let the Babel team take care of honoring the root .babelrc.

ide commented Nov 13, 2015

I've been testing master with Babel 6 for a few days and am arriving at the conclusion that we need to make a couple changes to Babel for RN 0.16. I think I have a pretty clear idea of the issues at hand:

  • We need a way for the RN packager to tell Babel to ignore .babelrc files (but not JS source files) under node_modules. Even if we were to add .babelrc to .npmignore, the .babelrc would still be present in local checkouts of Redux (ex: if you're using npm link or literally checked out redux under node_modules to work on it). Proposal: add an option to Babel like ignore-babelrc which is like ignore but applies only to .babelrc files.
  • We need decorators back, possibly as an unofficial plugin, to support libraries like react-redux and react-mixin.

@ide When this is resolved, it would help the community if you'd post the solution here. It seems quite a lot of people are confused on how to configure babel in a react-native project.
I would love to add to the docs to explain how to do it once there is a way that is working correctly with the latest version of babel, but at the moment I am a bit stuck, as are many others.


+1. I can't upgrade to v0.15 and use Redux because of the Babel 5/6 issues

But that's not as bad as the way v0.16.0rc blows up Xcode with compiler errors.

ide commented Nov 25, 2015

@adrian-social-prod Regarding the compiler errors, make sure you are using the latest version of Xcode.


@ide This might sound a bit crazy.. I'll probably be offered up to the open source gods, but.. Seeing that things are a bit broken with RN + Babel at the moment, perhaps rolling back to Babel 5 would help in the short run until Babel has been patched to support decorators (officially or unofficially) and to ignore node_module .babelrc files?

likidu commented Nov 30, 2015

+1. I'm blocked on migrating to Babel 6 due to both issues covered here: decoration and old .babelrc format.


Had the issue here #4516 - I'm using npm link mypackage inside my react-native project and this error occurred immediately after that.

@fson fson added a commit to reindexio/reindex-js that referenced this issue Dec 6, 2015
@fson fson Add .babelrc to .npmignore
Latest versions of react-native use Babel 6, which tries to read the
options from .babelrc in the installed reindex-js package and fails
because it has options for Babel 5. As a fix to this, remove .babelrc
from the published package by adding it to .npmignore.
(See: facebook/react-native#4062)
ajwhite commented Dec 7, 2015

I'm in the same boat as @adriansprod #4062 (comment) -- decorators and old .babelrc is a set back for us at the moment.

Currently exploring workarounds to use Babel 5 with 0.16.0, specifically by removing the babel 6 executable and having the packager use the globally installed babel 5 reactjs/react-redux#206 (comment)


One temporary workaround would be, to delete all .babelrc files in the npm postinstall hook,

    "scripts": {
        "postinstall": "find node_modules -type f -name .babelrc | grep -v /react-native/ | xargs rm"
skevy commented Dec 15, 2015

This was mine -

find node_modules -type f -not -regex \".*react-native\\/.*\" -name \".babelrc\" -exec rm -rf {} \\;

Yours is a little easier to parse :-p


@skevy Haha, that's nasty 😂

ajwhite commented Dec 15, 2015

Thanks for sharing @satya164, I think I'm going to go with that approach for now over #4062 (comment)


As a bit of a side-note, I can't help but think something is wrong when we have a separate GitHub repo for one tiny source file, with reams of extraneous files lying around, and no one bats an eye.

It was always possible not to pollute the global namespace with wild abandon, but the front-end hive-mind decided that no one should need to be able to arrange his <script> tags in the correct order (for his specific use-case), and therefore everything was to be in "modules", even though JavaScript itself didn't support modules.

And here we are. Every front-end project is littered with "standard" configuration files for extraneous tools that are not related to the actual software being delivered. We're supposed to write some JavaScript, and have browsers load and run it. It's not that complicated.

@skevy skevy referenced this issue in facebook/relay Dec 23, 2015

Discussion - using Relay offline #676

@thachp thachp referenced this issue in bartonhammond/snowflake Dec 30, 2015

Unable to build in IOS xCode #32

@thachp thachp referenced this issue in bartonhammond/snowflake Dec 30, 2015

Upgrade react-redux to v.4.0.6 throw UnableToResolveError #33

@weblogixx weblogixx referenced this issue in react-webpack-generators/generator-react-webpack Dec 30, 2015

new Parse.Query doesn't work with react-webpack?? #174

@skevy skevy referenced this issue in facebook/relay Jan 3, 2016

React Native Compatibility #713

@IanVS IanVS referenced this issue in gaearon/babel-plugin-react-transform Jan 7, 2016

Use without .babelrc #74

@Jonne Jonne referenced this issue in dozoisch/react-async-script Jan 15, 2016

Added babel rc to ignore file #7

@michaelcontento michaelcontento referenced this issue in michaelcontento/redux-storage Jan 19, 2016

throws TransformError in ReactNative 0.16 #65

@ajwhite ajwhite referenced this issue in Microsoft/react-native-code-push Jan 23, 2016

Application crashes after syncing new version #84

@ghost Unknown added a commit to facebook/relay that closed this issue Jan 28, 2016
@skevy skevy + facebook-github-bot-7 React Native Compatibility
**This PR depends on an unreleased version of `fbjs`, so DO NOT MERGE.**

When merged along with facebook/react-native#5084, facebook/fbjs#95, and whatever PR fixes facebook/react-native#4062 (which I will update this issue with when I push it), this fixes #26.

The changes to Relay itself are super minor here:

1. Remove the reliance on ReactDOM. The only use of ReactDOM is `unstable_batchedupdates`. So to fix, I abstracted the reference to `unstable_batchedupdates` to it's own module, and then took advantage of the "react-native" `package.json` option, supported by the React Native packager, to load the correct version of this function given the execution context.
2. Removed `react-dom` from peerDependencies (but kept it in devDependencies, for use in tests), and also upgrade the `fbjs` dependency to a (yet unreleased) version that provides better compatibility with React Native.
Closes #713

Reviewed By: yungsters

Differential Revision: D2872129

fb-gh-sync-id: f6ba6d06cfdde8ad8cbb0c7cd9d645f44f65e437
@ide ide reopened this Jan 28, 2016
@mikberg mikberg referenced this issue in facebook/relay Jan 29, 2016

Make Relay work with React Native out of the box #26

4 of 5 tasks complete
corbt commented Feb 4, 2016

The solution that I think we've standardized on is asking library authors to exclude .babelrc files from their npm packages, and the message has percolated through the ecosystem by now.

@corbt corbt closed this Feb 4, 2016
@lelandrichardson lelandrichardson added a commit to lelandrichardson/react-pure-render that referenced this issue Mar 12, 2016
@lelandrichardson lelandrichardson Add .babelrc to .npmignore for React Native compatibility
As discussed here: facebook/react-native#4062 , having .babelrc publish to NPM conflicts with parent projects that are using babel 6.
@lelandrichardson lelandrichardson added a commit to lelandrichardson/redux-immutable-state-invariant that referenced this issue Mar 15, 2016
@lelandrichardson lelandrichardson Add .babelrc to .npmignore for React Native compatibility
As discussed here: facebook/react-native#4062 , having .babelrc publish to NPM conflicts with parent projects that are using babel 6.
@audionerd audionerd added a commit to audionerd/redux-api-middleware that referenced this issue Apr 21, 2016
@audionerd audionerd ignore .babelrc on publish b54aa27
@ZauberNerd ZauberNerd added a commit to ZauberNerd/react-native-mock that referenced this issue May 23, 2016
@ZauberNerd ZauberNerd Ignore .babelrc through .npmignore to fix issue with react-native pac…

The react-native packager searches through all directories and parses
.babelrc config files if it finds any. This breaks the builds if these
.babelrc files are either for babel 5 or if they contain plugins unknown
to the parent project.

@see: facebook/react-native#4062
@ZauberNerd ZauberNerd referenced this issue in RealOrangeOne/react-native-mock May 23, 2016

Ignore .babelrc through .npmignore to fix issue with react-native #47

@jmurzy jmurzy referenced this issue in ReactTraining/history Aug 12, 2016
@mjackson mjackson Use separate .babelrc file 27a09b9
@cymen cymen referenced this issue in JFusco/es6-event-emitter Aug 26, 2016

.bablerc in npm package #1

steida commented Aug 27, 2016

gulp task for fixing that

import gulp from 'gulp';
import del from 'del';

gulp.task('native-fix', async () => {
  // github.com/facebook/react-native/issues/4062#issuecomment-164598155
  // This is a very long term issue. We can't fix whole npm.
  await del(['node_modules/**/.babelrc', '!node_modules/react-native/**']);

It's from https://github.com/este/este

@fson fson added a commit to fson/redux-optimist that referenced this issue Nov 3, 2016
@fson fson Remove .babelrc from the published package
Installed from npm, this package doesn't work with React Native,
because although the released code is transpiled, .baberc is
also published to npm.

Fixed by adding the `files` property in package.json to prevent .babelrc from being published.


Processing npm modules with babel is a bug and will break many packages. This is not how any of the rest of the node.js/JavaScript ecosystem operates. This problem exclusively affects react-native.

ide commented Nov 3, 2016

@ForbesLindesay I think it's actually really important for npm consumers to do transpilation. That doesn't preclude authors from transpile as well (just do both) but there are a lot of benefits to transpiling node_modules that I wrote up here: https://gist.github.com/ide/e7b9181984933ebb0755c7367a32e7e8


There are times when you want to transpile things in node_modules, but this should be done under the assumption that the code in node_modules is pure, standards compliant JavaScript code. It should not make use of .babelrc files, and it should not add strict mode if the file wasn't already in strict mode. Running babel in its default mode on node_modules is highly risky and should be avoided. Having the ability to run carefully chosen transforms against node_modules may be useful in the future, but it is a pretty specialised use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment