symbolic link duplicate module load

I am using handlebars-loader and when node_modules folder is linked from some other location Handlebars.SafeString is loaded from two location moduleA.SafeString and moduleB.SafeString

bundle if you search inside of this bundle you will find two instance of function SafeString

I have created demo so you can reproduce
https://github.com/feroc1ty/webpack-symbolic-link-bug

Author: Fantashit

5 thoughts on “symbolic link duplicate module load

  1. The symbol link problem is still exists. I already update webpack to 1.10.1.
    My situation:
    project A depent on react. npm link material-ui in project A. Also material-ui dependent on react. After webpack compile, duplicate react modules exists in the bundle file.

  2. FYI, for others that come here. I was in a situation like @jhnns mentioned, where I’m relying on not resolving the symlinks (otherwise relative paths inside a symlinked module didn’t work, because the resolved symlink ends up in a different directory than the file referred to by the relative path).

    Fortunately, I figured out how to get around this by writing a Webpack plugin that prevents ResultSymlinkPlugin from running: timmfin/broccoli-webpack-cached@5dfcd31

  3. One workaround I’ve found is that you have to go into your parent project’s node_modules and npm link all the dependencies that are shared with the modules you want to work on locally.

    Example using React library:

    1. cd parentProj/node_modules/react.
    2. npm link.
    3. cd myLocalModuleThatParentProjUses/node_modules.
    4. npm link react.

    Then you are guaranteed that both the parent project and the child module you are working on locally will use the same lib. After you are done make sure to unlink everything. It’s a huge headache when developing locally with modules. As much as I love the flexibility of Webpack, I never had these symlink/duplicate issues when using Browserify. I hope that this information helps people with this problem.

  4. Within the context of npm link and react development the following worked for me as a work around:

    resolve: {
        modulesDirectories: ["node_modules"],
        alias: {
          "react": NODE_MODULES_DIR + "/react",
    ...

    PS: I only have this issue w$ndows

  5. @jessepollak (and for anyone else struggling with an npm linked dependency)

    Until this is addressed in a more permanent way, I’ve found a really good solution is to share a single node_modules directory between the two dependant packages of the symbolically-linked dependency.

    It sounds a bit hacky, but after you get over the shock, it comes with a number of benefits. As long as your packages share the same dependency version requirements (i.e. one doesn’t rely on an outdated module), simply creating a symbolic link to the first package’s node_modules directory before installing the second package eliminates the issue entirely. Likewise for as many packages as needed. (It’s actually very possible to do this even with some clashing versions, though that requires some remapping of names.)

    I’ve found this is particularly valuable for monorepo projects with multiple similar packages because it also slashes install time and total dependency weight significantly. See bitpay/icv2/package.json for our post-install script (and a working example monorepo).

    Basically:

    cd first && npm install && cd ../
    cd second && ln -s ../first/node_modules/ node_modules && npm install && cd ../
    cd third && ln -s ../first/node_modules/ node_modules && npm install && cd ../
    [...]
    cd first && npm link my-module
    

    Each npm install adds it’s dependencies to the symlinked node_modules directory. Now you have a single directory of dependencies shared across the entire project, with no chance of strange interactions caused by my-module being a symbolic link.

Comments are closed.