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

[ide]

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

[sebmck]

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]

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]

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.

[hendrikswan]

@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.

[adriansdev]

+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]

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

[hendrikswan]

@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]

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

[niftylettuce]

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

[atticoos]

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 reduxjs/react-redux#206 (comment)

[satya164]

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]

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

[satya164]

@skevy Haha, that's nasty 😂

[atticoos]

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

[jugimaster]

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.

[steida]

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

[ForbesLindesay]

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]

@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

[ForbesLindesay]

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.