RN's package.json specifies in-exact version numbers, which routinely breaks builds. #12772

MattFoley · 2017-03-07T20:56:22Z

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

The text was updated successfully, but these errors were encountered:

ide · 2017-03-07T21:09:07Z

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.

brentvatne · 2017-03-07T21:16:05Z

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. @ide I think we could also tighten up the ^ to ~ to reduce the odds of this happening.

MattFoley · 2017-03-07T21:18:50Z

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 ***@***.***> 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 · 2017-03-07T21:19:35Z

Thanks Brent, that's exactly what I ended up doing to fix this issue this morning. It just took me a few hours to track this down as the problem.

…

Sent from my iPhone

On Mar 7, 2017, at 1:16 PM, Brent Vatne ***@***.***> 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 ***@***.*** -save — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

MattFoley · 2017-03-07T21:20:55Z

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 ***@***.***> 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 ***@***.*** -save — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

duhseekoh · 2017-03-08T05:56:41Z

Just re-bundled and can confirm the change in the uglify repo fixed the issue. I was experiencing this issue on RN 0.36.1 today.

ide · 2017-03-08T06:10:17Z

Nice effort put in by @brentvatne to help with the debugging to get a patch out. Going to close this issue since we think it's been resolved upstream. If you're running into this problem, clear your node_modules (or yarn upgrade) and try installing them fresh again.

kyle-ssg · 2017-03-08T11:01:22Z

I gather this is why I'm getting Unhandled JS Exception: Can't find variable: runInContext running a release build. However yarn add uglify-js@2.8.5 -save didn't seem to solve this. Is this issue unrelated?

edit: Yes it was unrelated, the js file was silently failing to minify due to an incorrect and unused js import. If anyone with the same issue spots this I'd recommend manually bundling JS order to debug these sorts of issues with react-native bundle --platform ios --dev false --entry-file index.ios.js --bundle-output iOS/main.jsbundle

MattFoley · 2017-03-08T14:50:43Z

That's the same problem. You'll want to verify that 2.8.5 was installed (check the output). I actually changed my package.json manually to 2.8.5.

…

Sent from my iPhone

On Mar 8, 2017, at 3:02 AM, Kyle Johnson ***@***.***> wrote: I gather this is why I'm getting Unhandled JS Exception: Can't find variable: runInContext running a release build. However yarn add ***@***.*** -save didn't seem to work for me. Is this issue unrelated? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

duhseekoh · 2017-03-08T14:56:13Z

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.

kyle-ssg · 2017-03-08T15:11:26Z

Ah right, I think in my case it was an unfortunate combination of the two issues in that case - I'd already got 2.8.5 before diagnosing my import issue. Glad this is sorted anyway!

brentvatne · 2017-03-08T16:37:37Z

Resolved in mishoo/UglifyJS#1573

dslounge · 2017-03-09T21:21:37Z

Oh man, the last two days have suucked because of this. Eat your vegetables and shrinkwrap your dependencies kids.

kevinhylant · 2017-03-09T21:42:11Z

Thank you for figuring this out! @MattFoley
I had literally just upgraded React-Native & React so I had re-yarn.lock-ed (bad timing, I guess)

petermikitsh · 2017-03-11T01:45:20Z

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.

MattFoley · 2017-03-14T00:55:37Z

@brentvatne / @ide I believe I'm running into this same problem again just now, and I'm digging into what the specific issue is.

I'm looking at an old version of my code base that hasn't changed in months, and when rebuilding now, a ListView in that version no longer works properly, and I'm seeing a slew of dependency differences from the npm install. These are all coming from automated build jobs, so user error is doubtful. Will re-ping this thread if I solve it, currently looking at uglifyjs again, which was on v2.7.5 last this was built, and is now on v2.8.12.

MattFoley · 2017-03-14T01:22:44Z

That looks like that was the problem again. @brentvatne Thank you for adding that to the package.json! (v2.7.5 was exactly the right version to be on it looks like!)

Summary: As per uglify-js maintainer kzc's comment in mishoo/UglifyJS#1573 (comment) we should be locking our version to prevent issues like #12772 from happening again. No test plan needed, people are already using this version of uglify-js (it's the latest). Closes #12802 Differential Revision: D4749853 Pulled By: javache fbshipit-source-id: 866a19cb2c1add31b55e14d0f4dadb7f68fda64c

brentvatne mentioned this issue Mar 7, 2017

v2.8.8 breaks React Native mishoo/UglifyJS#1573

Closed

ide closed this as completed Mar 8, 2017

brentvatne added a commit to expo/react-native that referenced this issue Mar 8, 2017

[uglify-js] Lock version to 2.8.9 to avoid breakage like facebook#12772

317c268

brentvatne mentioned this issue Mar 8, 2017

[uglify-js] Lock version to 2.7.5 to avoid breakage like #12772 #12802

Closed

rkretzschmar added a commit to rkretzschmar/react-native that referenced this issue Apr 5, 2017

fix facebook#12772

117f6a7

hasLandon mentioned this issue Apr 5, 2017

Android APK crashes after start. #12835

Closed

facebook locked as resolved and limited conversation to collaborators May 24, 2018

react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 18, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

RN's package.json specifies in-exact version numbers, which routinely breaks builds. #12772

RN's package.json specifies in-exact version numbers, which routinely breaks builds. #12772

MattFoley commented Mar 7, 2017

ide commented Mar 7, 2017

brentvatne commented Mar 7, 2017 •

edited

MattFoley commented Mar 7, 2017 via email

MattFoley commented Mar 7, 2017 via email

MattFoley commented Mar 7, 2017 via email

duhseekoh commented Mar 8, 2017

ide commented Mar 8, 2017

kyle-ssg commented Mar 8, 2017 •

edited

MattFoley commented Mar 8, 2017 via email

duhseekoh commented Mar 8, 2017

kyle-ssg commented Mar 8, 2017 •

edited

brentvatne commented Mar 8, 2017

dslounge commented Mar 9, 2017

kevinhylant commented Mar 9, 2017 •

edited

petermikitsh commented Mar 11, 2017

MattFoley commented Mar 14, 2017

MattFoley commented Mar 14, 2017

RN's package.json specifies in-exact version numbers, which routinely breaks builds. #12772

RN's package.json specifies in-exact version numbers, which routinely breaks builds. #12772

Comments

MattFoley commented Mar 7, 2017

Description

Solution

Additional Information

ide commented Mar 7, 2017

brentvatne commented Mar 7, 2017 • edited

MattFoley commented Mar 7, 2017 via email

MattFoley commented Mar 7, 2017 via email

MattFoley commented Mar 7, 2017 via email

duhseekoh commented Mar 8, 2017

ide commented Mar 8, 2017

kyle-ssg commented Mar 8, 2017 • edited

MattFoley commented Mar 8, 2017 via email

duhseekoh commented Mar 8, 2017

kyle-ssg commented Mar 8, 2017 • edited

brentvatne commented Mar 8, 2017

dslounge commented Mar 9, 2017

kevinhylant commented Mar 9, 2017 • edited

petermikitsh commented Mar 11, 2017

MattFoley commented Mar 14, 2017

MattFoley commented Mar 14, 2017

brentvatne commented Mar 7, 2017 •

edited

kyle-ssg commented Mar 8, 2017 •

edited

kyle-ssg commented Mar 8, 2017 •

edited

kevinhylant commented Mar 9, 2017 •

edited