Add default .babelrc

[tgoldenberg]

This PR addresses issue #7821, where the app crashes due to a parent-directory .babelrc file.

Previously, a PR tried to submit a fix by adding a default .babelrc file in new React Native projects, but was rejected so as not to add a peer dependency to react native.

In this PR, a default .babelrc is created with standard presets { "presets": ["react-native"] }. The docs are modified to recommend using a version of NPM greater than 3. This would ensure that the default .babelrc does not cause any complications, as was noted by @janicduplessis for npm2.

As for tests, the .babelrc is tested for in the local-cli/__tests__/generator-tests.js file. I also ran all the internal tests with npm test and there was no difference in output after the specified changes.

[facebook-github-bot]

By analyzing the blame information on this pull request, we identified @hramos and @JoelMarcey to be potential reviewers.

[lacker]

What happens if they skip this step? Will it just break with npm 2?

[lacker]

In general there are a lot of reasons that people can't update npm, so I'm concerned about adding npm 3+ as a requirement for React Native. Could this be backward-compatible instead of a breaking change somehow?

[lacker]

What is the rejected PR you refer to?

[tgoldenberg]

@lacker Hi, the rejected PR was #7822

I'm going to try to add a specific error message if Babel is misconfigured, but trying to wrap my head around how to do that currently. I guess that would solve the specific problem in the issue referenced above. Also, then we don't have to specify a version of NPM. Can close this unless you have suggestions.

[lacker]

Oh, I see what's happening now. I don't think this PR is the right way to handle it - you shouldn't make a project rely on babel-preset-react-native, but then not add the dependency explicitly, and ask people to use npm 3 so that the transitive dependency works. Isn't it still a migration problem if React Native stops using babel-preset-react-native with this setup?

Overall I think we really need to fix the way that React Native does transpilation nonstandardly with respect to libraries. @mkonicek and @ericvicenti might have some thoughts here too.

[janicduplessis]

It would be really nice to stop running babel on node_modules by default and have libraries publish compiled version like for the web. Another alternative would be to have the packager read some field in package.json to decide if it should compile that library or not so the migration path would be easier for lib authors.

One major benefit of this is it would allow to have better babel transforms, for example we can't enable strict mode modules because externals libraries may not be compatible with it.

[ide]

I wrote up a gist on transpiled/untranspiled code here: https://gist.github.com/ide/e7b9181984933ebb0755c7367a32e7e8. It's really valuable to publish the original source code or lightly transpiled source code. Transpilation on the fly worked really well for fb www, and I think a system that supports the same will win out because it can provide a better debugging experience, can make use of modern JSVMs, can do optimizations like dead-export elimination (aka tree shaking) and so on. I think it's fine to publish transpiled code to npm, but in an additive way I find it important to also publish untranspiled (or partially transpiled) code and make use of it as we do today with the RN packager.

Sorry to derail, I think we should do what we need to make Babel/RNP work better so we can keep consumer-side transpilation.

[satya164]

@ide though it doesn't affect your proposal, I think you forgot one con of shipping untranspiled code (in the current situation of ).

• Transpiling everything in node_modules has the possibility of breaking a module which wasn't supposed to be transpiled. An example is, we cannot enable strict mode in the preset since it breaks any module that doesn't run in strict mode.

[lacker]

OK - so I am going to close this pull request because it does not seem like the right approach. It does seem like there are some fundamental problems with the current React Native + babel approach. If someone is interested in leading an effort to fix that, I'd love to chat with them and I think I could get some folks to help out.