Double symlink apparently doesn't work
chenglou opened this issue · 6 comments
cc @bsansouci
Symlinks inside a symlink
This worries me a bit because npm link will make a link from a global location to the project you want, and then npm link dependency will make a link from the current project to the global one which then links back to the actual dependency. Jenga was returning errors when I did that and removing 1 layer of indirection made Jenga work. I'm hoping it's just a matter of setting the right flags. I haven't had time to dig deeper into this though. Maybe asking the Jenga folks would be the fastest way to know.
We can also create our own link workflow. Using actual OS symlinks isn't what's most important about symlinks. What's most important is that we don't step on artifacts. That's what I've always meant when I've said "we should support symlinks for packages in Rebel". So, there's many ways to do this, and we could even create a .links text file that describes where packages are actually located (as opposed to assuming they're in the node_modules directory).
Then, regardless of how we implement the link, we need to make sure build artifacts don't step on each other. One way to do that is to make sure the top level package you're building has all the artifacts in its ./_build directory (this is the route I've suggested in the past). Another approach we haven't explored is still allowing the dependency to contain its own build artifacts but in a way that will never collide with other projects that link to it and are also trying to build it. A single directory myDependency/_build isn't sufficient, because MyPackage is linking to myDependency but so is YourPackage and we could have different build flags.
So, you could imagine MyPackage, and YourPackage (which reside at /Users/me/MyPackage, /Users/me/YourPackage respectively) have a "link" (however that's implemented) to MyDependency (which resides at /Users/me/MyDependency) and there are two build folders inside of MyDependency such as /Users/me/MyDependency/_build/_Users__me__MyDependency and /Users/me/MyDependency/_build/_Users__me__YourDependency. By having the linked package encode the absolute path of the package that requested the build (by replacing / with __), we avoid all conflicts without needing to store all build artifacts inside of the top level package.
This is a good solution too, although I would miss the ability to just delete _build/* from the top level package that I'm building and know that it deleted all the artifacts. It's okay though, we can just make a command like rebel cleanDeps.
What doesn't work here. Is only polling/watching broken? Or is everything broken. I wish we had a repro case to show the people who contribute to Jenga.
@jordwalke I am busy for a couple of days. If nobody writes repro case by then, I will investigate it.
npm link works on linux. Probably will work on OSX. @bsansouci Can you check once?