Skip to content

es6-global modules have incorrect paths when compiling dependencies via npm link #1691

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

Closed
TheSpyder opened this issue Jun 8, 2017 · 6 comments
Labels
discussion stale Old issues that went stale

Comments

@TheSpyder
Copy link
Contributor

I'm experimenting with a project setup where I develop both the main library and a dependency at the same time. I have both repositories local on my machine during development. This works well enough if I npm install the dependency from the local filesystem, but then I need to reinstall after every change in the dependency. I would like to use npm link to solve this, but bsb is producing incorrect paths for es6-global modules when I try.

Given the folder structure in the attached tarball, run the following commands:

cd foo
npm link bs-platform ../bar
bsb -make-world

If you then cat lib/es6_global/src/foo.js, Bar is referenced as import * as Bar from "../../../node_modules/bar/lib/es6_global/src/bar.js"; which is loading it via the symlink.

However, if you cat node_modules/bar/lib/es6_global/src/bar.js, the path to the stdlib is wrong:
import * as $$String from "../../../../foo/node_modules/bs-platform/lib/es6/string.js";

This appears to have resolved the real filesystem location of the stdlib in foo relative to bar.js, ignoring the fact that it was compiled as a symlinked dependency. In other words it will work if bar.js is loaded from the real filesystem location, but not the symlink location (and as shown above foo.js is loading it through the symlink).

I can think of two solutions:

  1. When compiling bar, use stdlib references that work via the symlink
  2. When compiling foo, refer to bar through the actual filesystem location instead of via the symlink

I don't think option 1 is really viable though, as it would mean that moving back to working in the bar project directly leaves you with compiled output that no longer works.

@bobzhang
Copy link
Member

bobzhang commented Sep 6, 2017

@TheSpyder

  1. Sys.getcwd does not respect the symlink
  2. "../../such/path" is not unique when we have symlink -- This will affect not only how rollup resolve .js file but also how we resolve npm package

This seems to be a hard problem, do you have any suggestions.
A promising solution is that we only call Sys.getcwd in bsb once and pass -bs-package-dir to bsc.exe so that it wont call Sys.getcwd which could cause inconsistency

@TheSpyder
Copy link
Contributor Author

Sorry, I only looked at the email notification at the time which was before you edited in the other details, and then filed it away and only just noticed it! I haven't hit the problem since I completed development of the library I was linking at the time.

I have two ideas:

  1. Avoid the bar compilation referring to the bs-platform in foo, requiring a separate copy. This would mean the stdlib ends up loaded twice, but would avoid the weird stdlib link issue.

  2. Use a system call to see if the referred dependency is a symlink, and if it is read the link (I believe that's also a system call) and use that in place of node_modules/bar (this is more or less the same as proposal 2 in my original description).

@BlueHotDog
Copy link

Is this issue still relevant? 3 years since the last update.

@TheSpyder
Copy link
Contributor Author

It’s not October yet 😉

I don’t use es6-global anymore so I can’t check, unfortunately.

@BlueHotDog
Copy link

I think it's still there due to the monorepo issue

@stale
Copy link

stale bot commented May 3, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale Old issues that went stale label May 3, 2023
@stale stale bot closed this as completed May 20, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion stale Old issues that went stale
Projects
None yet
Development

No branches or pull requests

3 participants