[Packager] doesn't resolve modules that are symlinks

[JaapRood]

As described in the browserify handbook you can use symlinks in the node_modules folder to reference modules. This is mainly useful for preventing ../../../../ requires.

With a symlink setup from the project root setup like:

ln -s src/app node_modules/app

in any file in the project you can:

var  app = require('app');
var somethingElse  = require('app/lib/something-else');

However, the packager can't resolve them: Requiring unkonwn module "app".

Edit:
Check out this repo to easily reproduce the error above:

https://github.com/JaapRood/react-native-packager-symlink-bug

[romanonthego]

is it a bug or is it by design?
symlinks would be really handy actually :(

[cgarvis]

Just ran into this trying to develop a npm library locally using npm link

[amasad]

I thought we supported this use case. Thanks

[mars]

Perhaps related, relative requiring a module above the iOS/React Native directory fails the same way:

// in index.ios.js
var Auth = require('../common/auth');

Error: Requiring unknown module "../common/auth". If you are sure the module is there, try restarting the packager.

I tried symlinking that higher-level directory within the React Native project to fix, but it failed as well, leading me to this issue.

[JaapRood]

I finally had some time to make an example to prove it's not working. Check out this repo which references the example app component through a symlink, which doesn't get resolved.

https://github.com/JaapRood/react-native-packager-symlink-bug

Now, if only I had any idea on why.

[amasad]

I have an internal fix for this. Aiming to get it out next sync :)

[brentvatne]

Awesome @amasad - looking forward to this, will make lib development easier

[JaapRood]

Great @amasad, that would be immensely helpful!

[romanonthego]

@amasad no pressure, but when to expect next sync? :) will it be in 0.6.0 release?

[romanonthego]

still an issues as to 0.6.0 and 0.7.0-rc ...

[amasad]

That's strange. I'll give @JaapRood's test project a spin see what the problem is.

[idmontie]

👍 Same problem here. Symlinks are very useful, especially when I don't want to make a node package just to share a component between two related React apps.

[romanonthego]

it generally usefull for many global acessible parts of your application: constants, configs, reusable components replacing react-native base components (styled Text for example)
and none of other methods of requiring modules from applications root seen to work too :( this is why i'm hoping for this one so much.

[brentvatne]

@amasad - any updates here?

[romanonthego]

👍

[ide]

Figured out a little more about the cause -- the issue goes away when switching to the Node-based watcher instead of the Watchman-based one. The watchman homepage says, "Watchman does not follow symlinks. It knows they exist, but they show up the same as any other file in its reporting." so this could be the root case.

Support for symlinks seemed to get pretty strong pushback in facebook/watchman#105 so perhaps the packager could use a combination of Watchman for most files and the Node watcher for symlinked packages. npm linked packages reside in the first node_modules directory (you'd have to go out of your way to end up with node_modules/pkg1/node_modules/<linkedpkg>), so that might simplify things a little. I tried adding a --noWatchman option to the packager but ran into fd limit issues unfortunately.

The npm link workflow is really important for anyone developing a React Native module so I do think this is a priority for the external RN community.

[goatfish]

I'm not sure if this is related or not. I have a symlinked folder for some of my js files in the project root. These are some internal libraries that are part of another repo. I am importing them using require('./lib/file') where lib is a symlink to a folder. This is working in the packager in 0.7.1 and not working in 0.8.0-rc. I am using io.js.

I figured I'd put this here in case some code is changing in 0.8.0-rc related to this bug...

[brentvatne]

@amasad - seems like this was working for some people in 0.7.1 and not in 0.8.0-rc, as reported in #2076

[xinthink]

For 0.8.0-rc, the problem is Fastfs._getRoot returns null, when the local module located outside of the app dir, because the packager can only resolve modules within the app dir by default.

To solve the problem, I must launch the packager with an additional argument --root=<path_to_local_module>.

I'm not sure what's the best solution for this issue?

[zhaiduo]

I use 0.8.0, after close all terminal, xcode, restart. then everything is OK.

[JaapRood]

For those who have missed the release of 0.9.0-rc it's listed there as a known issue.

[bradens]

Is there any good workaround here?

[gethinwebster]

I've found that this can be worked around by uninstalling watchman and therefore forcing react native to use the default node file watcher, however this does have speed drawbacks, and you can come up against issues with the number of files being accessed depending on the project.

-------- Original message --------
From: Braden Simpson notifications@github.com
Date: 14/08/2015 20:25 (GMT+00:00)
To: facebook/react-native react-native@noreply.github.com
Cc: Gethin Webster gethin.webster@agilityworks.co.uk
Subject: Re: [react-native] [Packager] doesn't resolve modules that are symlinks (#637)

Is there any good workaround here?

Reply to this email directly or view it on GitHubhttps://github.com//issues/637#issuecomment-131214239.

[amasad]

Sorry for the delay, was out for a while.

@amasad - seems like this was working for some people in 0.7.1 and not in 0.8.0-rc, as reported in #2076

What happened is that we started using watchman for the filesystem crawling. My understanding is that watchman doesn't follow symlinks but should treat them like any other file. Which in theory should still work. I can try to debug this soon. Alternatively we can add an option to force not using watchman for filesystem crawling.

[Mokto]

Hi guys, any update on this ?

My only way to develop a react native library is to git clone my repo inside my node_modules, isn't it ?

[braunsquared]

Hey guys,
I got tired with dealing with the symlink handling so I forked react-native and patched the packager to fix the issues I was having. This might not fix everyones issues but it has certainly fixed mine. The issue that I was having (and have had since the dawn of time in using react-native) was caused by the packagers inability of discovering peer dependencies on symlinked modules (npm link or yarn link). I've updated the resolver for the packager to be aware of the root paths of the project and automatically add these paths to the search query used to resolve modules. The prior implementation would try to be smart about resolving the paths based on the modules real path which breaks on symlinked modules.

Take it or leave it, but you are all welcome to use it. I've patched both the 0.42-stable branch and the 0.43-stable branch but haven't really tested 0.43 since it relies on an alpha version of react.

Github repo

To use 0.42-stable update package.json react-native dependency to:
"react-native": "https://github.com/braunsquared/react-native/tarball/b576d07039dfaa0045fcff8b463f7490a86a7465"

For 0.43-stable use:
"react-native": "https://github.com/braunsquared/react-native/tarball/843be3173f617de0e13fc219f1aa2a809b94d1a3"

[zandroid]

Not sure but probably node option --preserve-symlinks can help you somehow. https://nodejs.org/dist/latest-v6.x/docs/api/cli.html#cli_preserve_symlinks

I had similar problem with symlinked files/modules (but on regular node project) and this option resolves problems for me.

[ladas-larry]

We definitely need to find way how to run React Native Packager with --preserve-symlinks option.

[OscarGodson]

Any update on this? I was surprised to see npm and just normal *nix symlinks dont work at all

[kokokenada]

+1

[ittikorns]

+1

[silentcloud]

+1

[danidewitt]

+1

[ghost]

+1

[hramos]

Please avoid adding metoo +1 comments, as it distracts from the conversation. May I suggest using reactions instead?

[phil-r]

@hramos The main problem with reactions that they don't attract any attention, but I agree that seeing that many +1 is annoying.

[ivosabev]

I hope it is annoying enough so they finally fix a 2 year old issue.

[ThaJay]

probably not though
#9942

[ghost]

This wasn't in the original post, but please note that this isn't some obscure feature request. npm link, for example, uses symbolic links behind the scenes, so it breaks with that too. I can confirm that copying, rather then symlinking, does work, however that becomes impractical when working on different npm packages locally.

Also, I tried it on macOS and linux and same issue occurs.

[skellock]

The RN packager was built for Facebook's needs; which unfortunately (for us) didn't include symlinks.

But... packager will be getting some love shortly. Hoping to see some news this week.

In the meantime:

• Have a look at haul by the Callstack crew. Provided your symlink'd dependency doesn't have its own react-native dependency, this works really well. (if it does you can delete the files temporarily).
• It is possible to stage some work out of node_modules again with live reloading. Yes, it's pretty derpy, but pair it with a file watcher and it's better than nothing.

[gary-lo]

+1

[hramos]

Can you move this to https://github.com/facebook/metro-bundler now that the packager has been moved out of React Native?

[ghost]

Hey guys I found a pretty good workaround: cp -al <sourceDirectory> <destinationDirectory>.

Basically because react-native doesn't respect symbolic links, the files need to be indistinguishable from the real files with hard links. The problem with hard links is that they don't work for directories. cp -al will copy the directory structure while using hard links for every file. Now I can go back to my local node package and transpile the source files like normal, and the changes in the build files are automatically refleted in the node_modules/ of my other package. 👌

[ghost]

Update: this seems to only partially work. It does reflect the changes in my editor, for example, but react native won't notice the change until I 'save' the updated file (even though saving isn't changing the file contents).

[hramos]

Closing, please reopen in the metro-bundler repo.

[di]

See facebook/metro#1.

[fredbt]

+1 having the issue with npm link.
My use case is that I'm trying to share some code between two apps, so I'd have the following config:

-- app1
-- app2
-- shared

where I will writ components in the shared folder. I tried to use the idea from here: https://stackoverflow.com/questions/8088795/installing-a-local-module-using-npm
but when I ran npm start in app1 folder, it failed to load the bundles, even though I can see the symlink for "shared" in the node_modules of app1.

[hramos]

Locking conversation, now that this has been moved to facebook/metro#1.