-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
devDependencies and hoisting problem #91
Comments
One way we could fix this would be to ignore |
I like the idea |
This issue was brought up recently when a react-oss-js test assumed that it could copy the "react" module out of react-native-github/node_modules/ and it would contain its dependencies. This wasn't the case due to the hoisting approach we currently have. The test itself was questionably implemented so it shouldn't be a nail in the coffin for the way we currently handle devDependencies, rather, another data-point. |
npm (to my knowledge) doesn't handle |
I'll find a link tomorrow, I think I came around this issue on GitHub/npm. On Thursday, 7 July 2016, Sebastian McKenzie [email protected]
|
You are right, @kittens, I was misguided that this is the behaviour of npm 3 but it is not. |
sorry to drudge up an old issue, but was there ever any further discussion of this? is it possibly related to #1462? There seems to be a discrepancy between how yarn and npm hoist modules that are shared by packages specified in dependencies and devDependencies when installing with |
Implements a super basic offline cache integration
Npm3 does not hoist devDependencies because hoisting of devDependencies will affect the overall node_modules structure of regular dependencies.
Then npm install --prod and --dev may have possibly different application node_modules and it may cause unexpected app behaviour.
Any idea if this issue affects us and whether we should do the same?
The text was updated successfully, but these errors were encountered: