Incorrect Babel transforms when running with "npm link"

[artdent]

Description

If you use "npm link" (or "yarn link") on a React Native component repository imported by your main repository, the wrong Babel presets are used in the component repository.

Edit: the Babel error is fixable by adding the correct devDependencies in the component, but doing so exposes other problems during packaging. See below for updated repro steps.

Reproduction

https://github.com/artdent/NpmLinkDemo demonstrates the problem. This is a stock repository created from react-native init 0.37.0, with one extra commit to import and use an arbitrary component, 'react-native-snap-carousel'.

Component repository:

git clone https://github.com/archriss/react-native-snap-carousel
cd react-native-snap-carousel
yarn link

Main repository:

git clone https://github.com/artdent/NpmLinkDemo
cd NpmLinkDemo
yarn install
yarn link react-native-snap-carousel
npm start
react-native run-ios

Expected behavior: the component attempts to render.
Actual behavior: SyntaxError /Users/jacob/triggr/react-bug-repro/react-native-snap-carousel/index.js: Unexpected token (6:21)

The SyntaxError is on the 'static' keyword, which should be permitted by react-native Babel preset. Likewise with the spread operator. If you remove those unsupported features, you get syntax errors at the places that use JSX.

I had to do two workarounds in react-native-snap-carousel to get it working as it did without 'yarn link': add a .babelrc with the react-native preset, and add react as an explicit dependency. Neither of these should be necessary. (And the latter can cause version collisions very quickly.)

I believe that this is not the same issue as #637 (initial symlink support for the packager) or #4968 (nonspecific import resolution caching problems).

Additional Information

• React Native version: 0.37.0
• Other versions: yarn 0.16.1, npm 3.9.5, node 6.2.2, react-native-cli 1.2.0, react 15.3.1
• Platform: both
• Operating System: MacOS

[hramos]

cc @mkonicek

[lacker]

I thought different Babel presets basically aren't supported, and you should be using the babel-preset-react-native everywhere.

[artdent]

I'm not trying to use a non-standard Babel preset. The bug is that the standard one, babel-preset-react-native, is not applied correctly to files in the repository referenced via npm link.

[ericvicenti]

I think the babel preset should always be defined in the .babelrc. So I believe that is the expected behavior.

You should specify "react" as a peerDependency in your package.json, not a direct dependency. Does that work?

[artdent]

@ericvicenti Which repository's package.json are you referring to? In the repro that I've posted, the main repository (which was created with react-native init) has react as a direct dependency, and the component repository (an arbitrary React component that I do not control) does not depend on react at all. I believe that that's all correct; it would be better for react-native-snap-carousel to specify react as a peer dependency, but that doesn't affect this bug.

Similarly, the main repository has a standard .babelrc containing babel-preset-react-native, and the component repository has no babelrc. This was all specified in my original report.

[ericvicenti]

The "an arbitrary React component that I do not control" should absolutely have react as a peerDependency, because it is a React component (even for functional components, JSX depends on React).

From my understanding, the component repository SHOULD have a babelrc that points to the rn preset.

I know you aren't the component author in this case, but maybe you can submit a PR to the repo to fix these things? Or you could fork it.

[artdent]

The proposed fix -- adding .babelrc, plus a devDependencies entry on babel-preset-react-native -- solves half the problem. The component now fails to load with:

Unable to resolve module react from /Users/jacob/triggr/react-bug-repro/react-native-snap-carousel/index.js: Module does not exist in the module map or in these directories:
      /Users/jacob/triggr/react-bug-repro/react-native-snap-carousel/node_modules

    This might be related to https://github.com/facebook/react-native/issues/4968
    To resolve try the following:
      1. Clear watchman watches: `watchman watch-del-all`.
      2. Delete the `node_modules` folder: `rm -rf node_modules && npm install`.
      3. Reset packager cache: `rm -fr $TMPDIR/react-*` or `npm start -- --reset-cache`."

(The workarounds proposed in that error message don't fix the problem.)

If I give react-native-snap-carousel a dev dependency on react, rather than a peer dependency, then everything renders. That's the second half of the workaround that I described in my original report.

Unfortunately, that workaround breaks for components that depend on react-native (unlike react-native-snap-carousel, but like the non-oss components that caused me to file this bug). If you add a dev dependency on react-native in the component, then you end up with errors like the following when running npm start:

Error: @providesModule naming collision:
  Duplicate module name: String.prototype.es6
  Paths: /Users/jacob/triggr/triggr_native_components/node_modules/react-native/packager/react-packager/src/Resolver/polyfills/String.prototype.es6.js collides with /Users/jacob/triggr/triggr_native_ios/node_modules/react-native/packager/react-packager/src/Resolver/polyfills/String.prototype.es6.js

This error is caused by a @providesModule declaration with the same name across two different files.
    at HasteMap._updateHasteMap (/Users/jacob/triggr/triggr_native_ios/node_modules/react-native/packager/react-packager/src/node-haste/DependencyGraph/HasteMap.js:155:13)
    at module.getName.then.name (/Users/jacob/triggr/triggr_native_ios/node_modules/react-native/packager/react-packager/src/node-haste/DependencyGraph/HasteMap.js:115:31)
    at process._tickCallback (internal/process/next_tick.js:103:7)

And that error is where my knowledge of React internals is exceeded. It looks to me like one of the following holds:

1. the component should add devDependencies on react-native, etc., but there's a bug that causes @providesModule collisions as described above
2. the component should not have to add devDependencies on react-native, etc., in order to be usable with npm link.

[uqix]

@artdent same problem as yours, any progress?

[Exilz]

Same problem, I can't find a proper workaround that solves every case.
If you find one, I'd be happy to check your PR @artdent

[ericvicenti]

cc @davidaurelio @ljharb

[ljharb]

@artdent every react project should have both a peerDependency and a devDependency on react.

[artdent]

@ljharb That's sensible. If the project also imports, say, react-native and third-party components like react-native-mixpanel, should it include those in both peerDependencies and devDependencies? (My instinct is yes: for instance, unit tests won't work in that repository unless you have dev dependencies.)

[ljharb]

Yes. In every npm project, full stop, any form of dependency that's a singleton should be a peer dep with as wide a semver range as possible; anything that's a peer dep should also be a dev dep.