We’ve got an Expo project that imports a private NPM package called js-ui-components, which has react-native as a devDependency. Basically it’s a separate repo in which we put common reusable chunks of UI, and some of them use react-native components and utils.
Problem is, our main project that’s depending on our private js-ui-components ALSO requries react-native as a devDependency. When we use yarn link to develop this dependency locally, it leads to Ambiguous resolution errors because “there are several files providing this module” (react-native).
I’m also getting these issues when pushing the dependency to a branch on Github and including it that way. The only way it seems to build is if we just depend on the most up-to-date version in NPM, which is really inconvenient for development.
You can use local paths or GitHub references in package.json so that you don’t always need to publish to the npm registry. These are documented on npm’s website: https://docs.npmjs.com/files/package.json#dependencies.
npm link and yarn link currently have a fundamental issue in that they create a node_modules hierarchy that differs from what you’d see with normal npm install. This leads to differences between development and production, and downstream complexity because of that.
A possible workaround (haven’t tried this) could be to remove the devDependencies from your library and introduce a third package for testing your library, which would depend on react-native and other devDependencies.
That’s what I thought too, but it turns out I get the same exact problem from yarn add file:../js-ui-components. Only installing the published version from NPM seems to omit the devDependencies correctly. At least as far as Metro’s concerned; building the project with Webpack has no such issue (though maybe react-native-web, which we alias react-native to for Webpack, doesn’t care?).
Might need to just put a native storybook in the UI components library and develop it that way instead of in parallel with the main project.