Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
use lookup folder instead of cwd for symlink path resolution. Refs #9009 #9574
Explain the motivation for making this change. What existing problem does the pull request solve?
Fixes the symlink path resolution. See discussion here: #9009 (comment)
Test plan (required)
Symlink a required module by running
I did notice that although this resolves the symlink path issue, when the packager is resolving dependencies it's still unable to load my symlinked files. I still need to copy them into the project's
Might try and dig into that later today to see. @Kureev have you gotten symlinks working with your fixes? Were they just JS modules symlinked in or were did they have native pieces as well? I'd be curious to see a simple example if so.
Currently, the packager won't actually resolve symlinks if you are using watchman due to this issue: facebook/watchman#105.
After following the rats nest of dependency injection in the packager I've traced through what happens.
With my fix the symlinked modules are now being included in the haste map but not in the the
So... because the files are in the haste map but are never included in
At least that's how I think it works
After looking through all the related issues I have some proposed solutions:
Use the fallback node watcher
This seems like a simple and great solution for local development. However, given the number of dependencies with React Native V8 ends up running out of memory. Basically the fallback node watch is a no go. So it's not really a solution. I just put it here because it has been mentioned to just "brew uninstall watchman". That doesn't really work.
Fix Watchman to support Symlinks
Progress is being made here but it's slow and it seems like it's pretty complex. Way out of my element here.
@dutzi wrote a utility called
babel --watch -d /path/to/project/node_modules/symlinked_module/ /path/to/symlinked_module/src/
Any insight or suggestions on how we can fix this would be really helpful and greatly appreciated. I'm totally willing to help. The current solutions for developing local modules just aren't working well with teams and multiple modules. Even though @dutzi's
@ekryski, thanks for such a good and insightful investigation.
It might be possible to support file symlinks instead of folder symlinks, not sure if it is any useful for our case.
There is a hope that the new Mac OS version will fix the bug and then we might have it afterall.
It sucks that it crashes for RN codebase.
How about integrating WML solution into React Native?
What's the difference with "normal" watchman usage? I've tested it on a new project after PR has been merged and it worked for me. Do you have a very specific setup?
@Kureev I've got a package that I am symlinking into an example app in the same repo. I am attempting to use
This is simplified but that's the general structure. I'll try it out on a fresh app with a really basic symlinked package. @Kureev are you able to share your test app?
Bummer. Ya I don't know if that will help either. My hunch is it won't.
Not sure. I can poke around a bit but I think the only way would be to reduce the number of files/dependencies in RN. There are a lot. We are talking about the watcher processing ~3000 files.
Maybe there is a hack to tell node-watcher to allocate more memory as that might be a bandaid to avoid the out of memory exceptions. In any case it's still seems slower than watchman by quite a bit.
I had been thinking about that as well. Similar to what happened with rnpm. Have it as a command or have it auto-detect symlinked files. WML blew up a bit with my folder structure above (symlinked module being up one directory from where it is used) but when it is in a folder such that it is a sibling to the example app it works great.
The other solution I was thinking of is that we could have a different watcher (maybe node-watcher) just for symlinked modules. Maybe we'd still have memory issues (especially if the external modules are big or there are a lot of them).
I was also looking to see if you could set up watchman to watch the symlinked directory and tell it to copy files to the projects
The process being:
The way the packager looks for paths it should pick it up without issue because it will just think that the module is installed as a normal dependency.
The only potential hiccup is that
tl;dr: Shouldn't this merged asap so people who already had symlink in node_modules - for example universal js - don't run in ENOENT error in startup? (I had this issue, more precise use case bellow).
I already used symlinks in universal js (for server and tests), and was able to mimic the symlink behaviour with simple package.json like pointed here.
But this wrong symlink searching path made the app don't start with ENOENT error. And I if I changed the symlink to work with react-native would break the server and tests.
I tried to merge this pull request into the Facebook internal repo but some checks failed. To unblock yourself please check the following: Does this pull request pass all open source tests on GitHub? If not please fix those. Does the code still apply cleanly on top of GitHub master? If not can please rebase. In all other cases this means some internal test failed, for example a part of a fb app won't work with this pull request. I've added the Import Failed label to this pull request so it is easy for someone at fb to find the pull request and check what failed. If you don't see anyone comment in a few days feel free to comment mentioning one of the core contributors to the project so they get a notification.