using npm link with webpack causes issues as soon as require is used to load a symlinked module

[edeustace]

when packing a question we use npm link to link local dependencies. This is to allow us to support hot module loading for these local pies. However when node requires a module that is at a symlinked location, it's path is resolved to it's real path.

Eg:

mkdir ~/one && mkdir ~/two
echo "console.log(__dirname)" >> ~/one/my-module.js
ln -s ~/one/my-module.js ~/two/my-module.js
node ~/two/my-module.js //=> ~/one

This causes all sorts of issues for webpack if any linking is done in the symlinked module (ie vue-loader).

One alternative I'm investigating relates to using alias. Will report back shortly.
see:
nodejs/node#3402
webpack/webpack.js.org#145

[edeustace]

I think it's best not to use npm link for hot module loading, instead we'll have to set up a watch on the local pie srcs and copy them across. It's more effort, but it'll be easier than trying to get the linking working. will have a look tomorrow.

[cdosborn]

You may want to check this out:
http://webpack.github.io/docs/troubleshooting.html#npm-linked-modules-doesn-t-find-their-dependencies

[edeustace]

Thanks I'll check it out.

[edeustace]

I've looked into using fallback and it works (using node >=6.7.0 and npm >=3.9.3. However it requires that both the pie defines devDependencies for use in building and the same dependencies are needed in the question's build (added via the framework support). This is because the fallback property adds a discrete module loading context which needs the relevant dependencies.

I have to pick something and move on right now, and I'll go with the alternate approach (removing link and setting up a watch). I think on the build side it's simpler, and we'll have good control over the watch. There are many other issues that need to be addressed so it's better to move on to allow these other issues to get some air time. Then at a later stage we can re-visit this.