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

[MattFoley]

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

[ide]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Resolved in mishoo/UglifyJS#1573

[dslounge]

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

[kevinhylant]

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]

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]

@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]

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!)