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

Closed
worldsayshi opened this Issue Nov 2, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@worldsayshi

worldsayshi commented Nov 2, 2016

Reproduction recipe here: https://github.com/worldsayshi/meteorRequireProblems

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:
#2876
#7154

@worldsayshi

This comment has been minimized.

worldsayshi commented Nov 2, 2016

Made slight adjustment to example readme just now.

@DrDanRyan

This comment has been minimized.

Contributor

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 1.4.2.1 milestone Nov 4, 2016

@benjamn benjamn self-assigned this Nov 4, 2016

@benjamn

This comment has been minimized.

Member

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