react-native: RN's package.json specifies in-exact version numbers, which routinely breaks builds.

Description

The package.json for this project specifies almost all dependencies with a ^. This routinely breaks older builds.

React Native 0.32.1 was previously using uglify-js 2.8.5. This morning/last night uglify-js published v2.8.8. Since RN specifies "uglify-js": "^2.6.2" in it’s package.json, npm began pulling in the latest v2.8.8.

This new version of uglify-js now conflicts with lodash 4.1.x usage alongside react-native. Our build which worked just fine yesterday was broken by this change. runInContext was no longer defined correctly on a release/minified build from the react-native packager. See npm page here for release history of uglify-js.

Comparison of symbol definition change causing this breakage:

uglifyjs@2.8.5:

e.runInContext=n

uglifyjs@2.8.8:

r.runInContext=runInContext

This change meant that our JS file threw an exception on load, and was completely broken. This has to be the dozenth time this has happened to since switching to React Native, and has wasted countless hours.

Solution

Stop using in-exact versions. Specify exactly the version of dependency you need. (Why on earth would you want dependency version changes happening underneath you?)

Additional Information

React Native version: 0.32.1
Platform: iOS/Android
Operating System: OSX

About this issue

Original URL
State: closed
Created 7 years ago
Reactions: 6
Comments: 17 (2 by maintainers)

Commits related to this issue

[uglify-js] Lock version to 2.8.9 to avoid breakage like #12772 — committed to expo/react-native by brentvatne 7 years ago
Lock version to 2.7.5 to avoid breakage like #12772 Summary: As per uglify-js maintainer kzc's comment in https://github.com/mishoo/UglifyJS2/issues/1573#issuecomment-284940371 we should be locking o... — committed to facebook/react-native by brentvatne 7 years ago
fix https://github.com/facebook/react-native/issues/12772 — committed to rkretzschmar/react-native by rkretzschmar 7 years ago

Most upvoted comments

Definitely switching to yarn, but that wouldn’t fix this issue for new projects. i.e.: If I had started a new project, which didn’t yet have a yarn.lock file, it would pull in the wrong versions of RNs dependencies, and this new yarn.lock file would be still be incorrect.

Sent from my iPhone

On Mar 7, 2017, at 1:10 PM, James Ide notifications@github.com wrote:

Using exact versions in package.json doesn’t solve this thoroughly because of transitive dependencies. Use yarn.lock on the app developer’s side if you want to defend against this.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

MattFoley on Mar 7, 2017

To be fair, Ide is right, this isn’t just a problem with React Native, but more a problem with the JS npm ecosystem as a whole. Having RN specify exact dependencies would at least help a little bit. 😃

Sent from my iPhone

On Mar 7, 2017, at 1:16 PM, Brent Vatne notifications@github.com wrote:

Thanks for catching this @MattFoley. I agree that using yarn.lock would help you avoid this problem on your app, although what happens for new projects? The template for init doesn’t include yarn.lock and so all new projects will break. For people still using npm there isn’t much they can do either (I guess theres shrinkwrap, but…)

I was able to fix this on someone’s project by running yarn add uglify-js@2.8.5 -save

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

MattFoley on Mar 7, 2017

Well, that was an hour of my life I won’t get back. Glad I found this issue. This is impacting newer versions as well. I’m on RN 0.41.2 and npm i --save uglify-js@2.8.9 fixed the problem.

petermikitsh on Mar 11, 2017

Uglify 2.8.9 (published a few hours ago) the latest works. It was only 2.8.8 that broke RN. Shouldn’t need to lock in at 2.8.5 as was previously suggested.

duhseekoh on Mar 8, 2017