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

[1.4.2] 'require' seems broken in dependency when using 'meteor npm link' #8005

worldsayshi opened this Issue Nov 2, 2016 · 3 comments


None yet
3 participants

worldsayshi commented Nov 2, 2016

Reproduction recipe here:

In short: I can't use require("./foobar.js") in the imported module when I use meteor npm link ../path/to/dependency. require seems to be confused about how to find modules by relative path.

Related issues, possibly same issue:


This comment has been minimized.

worldsayshi commented Nov 2, 2016

Made slight adjustment to example readme just now.


This comment has been minimized.


DrDanRyan commented Nov 3, 2016

I am having the same issue; any require calls to a relative path in the "main" file of the linked package lead to a "module not found" error.

@benjamn benjamn added this to the Release milestone Nov 4, 2016

@benjamn benjamn self-assigned this Nov 4, 2016


This comment has been minimized.


benjamn commented Nov 4, 2016

Thanks very much for the reproduction. Fix coming soon!

@benjamn benjamn closed this in af51b81 Nov 9, 2016

benjamn added a commit that referenced this issue Sep 6, 2018

Simplify external symlink handling in Builder#copyDirectory.
Follow-up to af51b81, which fixed #8005 by copying symlinks to external
directories as directories rather than trying to preserve the symlinks.

Issue #10177 revealed a flaw in this strategy: the filter function that we
use to strip development npm packages always rejects external paths, even
if the original symlink was found in a valid production npm package, and
thus its contents should be included in the production bundle.

In the process of fixing this problem, I realized that the only important
part of af51b81 was this code:

  // Update fileStatus to match the actual file rather than the
  // symbolic link, thus forcing the file to be copied below.
  fileStatus = optimisticLStatOrNull(externalPath);

and the code for manipulating thisAbsFrom and _currentRealRootDirectory
could be removed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment