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

[TheSpyder]

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]

@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]

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]

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

[TheSpyder]

It’s not October yet 😉

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

[BlueHotDog]

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

[stale]

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.