Skip to content
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

Paths are not normalized on Windows, causing duplicates #3752

Closed
Venryx opened this issue Jun 7, 2017 · 5 comments
Closed

Paths are not normalized on Windows, causing duplicates #3752

Venryx opened this issue Jun 7, 2017 · 5 comments
Labels

Comments

@Venryx
Copy link

Venryx commented Jun 7, 2017

For package: jest-haste-map

What is the current behavior?

Running the react-native packager (react-native start) with watchman enabled (ie. in the path) fails on Windows.

This is because the paths that are put into jest-haste-map do not have consistent path-separators.

For my project, I did a test to show this.

In "C:\Root\Apps@V\LucidLink\Main\node_modules\jest-haste-map\build\HasteFS.js", I added the following lines:

  constructor(files) {
    this._files = files;
+    for (let filePath in files) {
+      console.log(filePath);
+    }
  }

When I ran "react-native start", I then got these results:

[...]
C:/Root/Apps/@V/LucidLink/Main\Build/LucidLink/More.js
C:/Root/Apps/@V/LucidLink/Main\Build/LucidLink/Journal.js
C:/Root/Apps/@V/LucidLink/Main\Build/LucidLinkUI.js
C:/Root/Apps/@V/LucidLink/Main\Build/LucidLink.js
C:/Root/Apps/@V/LucidLink/Main\Build/index.android.js
C:/Root/Apps/@V/LucidLink/Main\Build/EarlyRun.js

Note that forward slashes are used everywhere except for the divide between the root folder and the folder under it.

This causes problems, because the other scripts, which call the HasteMap.exists method, pass in file-paths which follow a different pattern (they're all backslashes, as per Windows). This means that the HasteMap.exists method returns "false" for many file-paths which, in fact, exist. This causes real-files to appear to be missing, causing module-not-found errors.

Here's an example of the error: (when the file does in fact exist -- even when copied into both roots)

(node:54964) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 2): NotFoundError: Cannot find entry file index.android.js in any of the roots: ["C:\\Root\\Apps\\@V\\LucidLink\\Main","C:\\Root\\Apps\\@V\\LucidLink\\Main\\Build"]

It also causes duplicate entries to be added to the HasteMap, causing duplicate-module warnings.

Here's an example of the warnings it causes:

@providesModule naming collision:
  Duplicate module name: NavigationCardStack
  Paths: C:/Root/Apps/@V/LucidLink/Main\node_modules/react-native-experimental-navigation/NavigationCardStack.js collides with C:/Root/Apps/@V/LucidLink/Main\node_modules/react-native/Libraries/CustomComponents/NavigationExperimental/NavigationCardStack.js

This error is caused by a @providesModule declaration with the same name across two different files.

This took me about 10 hours to track down, because I followed many false and halfway-fixing leads before finally coming across the root issue. (stumbling around in react-native's javascript files is not exactly my speciality)

What is the expected behavior?

The HasteMap class should normalize all stored file-paths, and the file-paths compared with those in the store.

This is pretty straight-forward. In my case, I fixed the problem by making these changes, to the "jest-haste-map\build\HasteFS.js" file:

  constructor(files) {
-    this._files = files;
+    this._files = {};
+    for (let filePath in files) {
+      this._files[path.normalize(filePath)] = files[filePath];
+    }
  }

[...]

   exists(file) {
-    return !!this._files[file];
+    return !!this._files[path.normalize(file)];
  }

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.

OS: Microsoft Windows 10 Pro (Version 10.0.14393 Build 14393)
node: 6.9.1
npm: 3.10.8
jest: 17.0.2
jest-haste-map: 18.0.0

End note

Please consider adding these changes (or an equivalent), as it is quite hard to track down for end-users!

I don't know what caused my project to have this issue, without being the case for all watchman-enabled Windows projects. It's possible it was caused by some kind of misconfiguration.

But even if that's the case, it's still a serious problem because:

  1. No errors or warnings are shown to tell me of my configuration mistake.
  2. When it happens, it's very annoying and time-wasting. (I've spent ~10 hours debugging, and time was also lost in the weeks earlier, where I settled for using the node file-watcher -- which had major problems of its own for me)
  3. It seems like the mistake, if there was one, must be fairly easy to make, as I've done little "out of the ordinary" with my project setup.

Anyway, for reference, here is the project I encountered the issue in: https://github.com/Venryx/LucidLink

And here is a thread with some other background on the issue: facebook/react-native#9136 (comment)

I know providing a direct repro project is easier for debugging, but in this case the problem and solution are straight-forward enough that I don't think it's necessary. (and I've spent an awful lot of time on this issue already)

If you need any specifics from my project though, feel free to ask, and I'll provide them here for convenience.

@atrich-ms
Copy link

@Venryx, are you still experiencing this issue? And are you still working around it as above? I'm seeing it on my machine but my colleague is somehow not experiencing this.

OS: Microsoft Windows 10 Enterprise (Version 1703, OS Build 15063.540)
node: 6.11.2
npm: 3.10.10
jest: 20.0.4
jest-haste-map: 18.0.0

Watchman version: 4.9.0

@kumarharsh
Copy link

Isn't this fixed by #4018?

@SimenB
Copy link
Member

SimenB commented Oct 11, 2017

I'd guess so. @Venryx could you check?

@thymikee
Copy link
Collaborator

Should be fixed by #5553

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 13, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants