0.55.x (latest: 0.55.4)

[grabbou]

Latest release: 0.55.4

[grabbou]

Status: Branch cut
Date: 06/03/2018
Next update: 06/03/2018
Expected status: CI tests passing

[grabbou]

Status: CI tests failing
Date: 06/03/2018
Next update: 06/03/2018
Expected status: CI tests passing
Note: There seems to be an unexpected error due to Metro bundler version mismatch. Teams are aware of the problem. I'll be following up later today.

[grabbou]

Status: CI tests failing
Date: 07/03/2018
Next update: 07/03/2018
Expected status: CI tests passing
Note: Apologies for radio silence yesterday, but didn't have enough time to check with Metro team what's going on. I'll attempt fixing the issue today, we hopefully go green really soon.

[grabbou]

Status: CI tests failing
Date: 09/03/2018
Next update: 09/03/2018
Expected status: CI tests passing
Note: CI is failing because of a really odd issue (anyone has an idea?) Basically, commit on master passes, whereas same commit breaks on release branch. I have few ideas but waiting for Hector from FB team to check this internally. I can't promise it's going to get fixed today, but I'll definitely update you later in the day.

[motiz88]

@grabbou You want to link to an example build that's failing? Very naively I'd guess it could be a caching issue (maybe dependencies of some kind?), with the existing cache for master helping the build pass while the code actually has an issue when the cache from previous builds isn't there.

[grabbou]

Yeah, my guess was also that the cache on Circle CI 2.0 has wrong keys (fallback ones) which fails for the first time on any branch where there's no specific cache.

Here's failing test: https://circleci.com/gh/facebook/react-native/36435

[motiz88]

Looks like a recurrence of facebook/react-native#17742. (@grabbou do you want me to move this elsewhere?)

The failure

The test_ios Circle CI build is failing with:

Error: Unable to resolve module `metro/src/lib/bundle-modules/HMRClient`
  from `/Users/distiller/react-native/Libraries/Utilities/HMRClient.js`:
  Module does not exist in the module map

The state of the filesystem

The actual build filesystem on CircleCI (as cached at the end of https://circleci.com/gh/facebook/react-native/36269) seems to include both HMRClient.js and HmrClient.js in the requested location:

...
./node_modules/metro/src/lib/bundle-modules/MetroClient.js
./node_modules/metro/src/lib/bundle-modules/HMRClient.js.flow
./node_modules/metro/src/lib/bundle-modules/MetroClient.js.flow
./node_modules/metro/src/lib/bundle-modules/asyncRequire.js.flow
./node_modules/metro/src/lib/bundle-modules/asyncRequire.js
./node_modules/metro/src/lib/bundle-modules/HMRClient.js
./node_modules/metro/src/lib/bundle-modules/HmrClient.js
./node_modules/metro/src/lib/bundle-modules/BUCK
./node_modules/metro/src/lib/bundle-modules/HmrClient.js.flow
...

The potential fix

In facebook/react-native#17742 it was pointed out that facebook/react-native@e048bf1 (requiring HmrClient instead of HMRClient) fixed things. My hypothesis as to why master is working is that it has a cache from a time when HmrClient was requested, which a clean build cannot reconstruct.

This is likely to be an unreliable fix in the long run; the problem could be down to nondeterministic behaviour in metro with filenames that are only distinguishable by letter case, e.g. relying on readdir sort order where it is not actually guaranteed to be consistent.

However, based on circumstantial evidence, I believe that changing https://github.com/facebook/react-native/blob/26684cf3adf4094eb6c405d345a75bf8c7c0bf88/Libraries/Utilities/HMRClient.js#L16 to require HmrClient will fix the build for the time being.

[grabbou]

Thanks for digging into that! I have applied the suggested fix and will try to see whether it makes the build green. It worries me that the referenced issue says that it has been fixed in `master` which is clearly not true. I'll pass this thread to Facebook team to see what's their idea. Thank you! You saved me few hours of digging :)

…

On Fri, 9 Mar 2018 at 19:33 Moti Zilberman ***@***.***> wrote: Looks like a recurrence of facebook/react-native#17742 <facebook/react-native#17742>. ***@***.*** <https://github.com/grabbou> do you want me to move this elsewhere?) The failure The test_ios Circle CI build is failing with: Error: Unable to resolve module `metro/src/lib/bundle-modules/HMRClient` from `/Users/distiller/react-native/Libraries/Utilities/HMRClient.js`: Module does not exist in the module map The state of the filesystem The actual build filesystem on CircleCI (as cached at the end of https://circleci.com/gh/facebook/react-native/36269) seems to include both HMRClient.js and HmrClient.js in the requested location: ... ./node_modules/metro/src/lib/bundle-modules/MetroClient.js ./node_modules/metro/src/lib/bundle-modules/HMRClient.js.flow ./node_modules/metro/src/lib/bundle-modules/MetroClient.js.flow ./node_modules/metro/src/lib/bundle-modules/asyncRequire.js.flow ./node_modules/metro/src/lib/bundle-modules/asyncRequire.js ./node_modules/metro/src/lib/bundle-modules/HMRClient.js ./node_modules/metro/src/lib/bundle-modules/HmrClient.js ./node_modules/metro/src/lib/bundle-modules/BUCK ./node_modules/metro/src/lib/bundle-modules/HmrClient.js.flow ... The potential fix In facebook/react-native#17742 <facebook/react-native#17742> it was pointed out that ***@***.*** <facebook/react-native@e048bf1> (requiring HmrClient instead of HMRClient) fixed things. My hypothesis as to why master is working is that it has a cache from a time when HmrClient was requested, which a clean build cannot reconstruct. This is likely to be an unreliable fix in the long run; the problem could be down to nondeterministic behaviour in metro with filenames that are only distinguishable by letter case, e.g. relying on readdir sort order where it is not actually guaranteed to be consistent. However, based on circumstantial evidence, I believe that changing https://github.com/facebook/react-native/blob/26684cf3adf4094eb6c405d345a75bf8c7c0bf88/Libraries/Utilities/HMRClient.js#L16 to require HmrClient will fix the build for the time being. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACWcxiwfM4OkCMieHeYiO8mKy7hojnSvks5tcsr5gaJpZM4SdoaG> .

[hramos]

Amazing. Thanks for looking into this. It makes total sense and explains the flaky test behavior.

[hramos]

I'm landing a fix. We were using a stale node_modules cache. While the same cache is used by all jobs in the tests workflow, the issue would only surface on workflows running on case insensitive OS X machines.

i.e. when the cache was restored and the workspace attached unto our Ubuntu containers, we'd end up with the stale HmrClient.js as well as the correct HMRClient.js file, and we'd happily move along.

On OS X, however, upon attaching the workspace we'd end up with a single HmrClient.js file which is not what we expect.

Note that this all comes from an issue we had with Metro. The release that preceded 0.25 was published to npm with the wrong case, i.e. it had HmrClient.js in the published package, even though the repo itself was tracking HMRClient.js. This happened due to a mismatch of case sensitiveness between the machines hosting our repo and the developer's machine that published the package.

As part of my fix, I added a regression test to ensure this doesn't happen again.

[hramos]

Note that my fix is landing on master, we might need to cherry-pick it unto 0.55-stable.