webpack: Webpack dependencies fail with npm linked package.

Same here, wondering if yarn is the issue.

Update: happens with npm as well.

Worked for me: Turn off symlink resolution in webpack via resolve: { symlinks: false }.

Credit to this answer in #1866.

http://webpack.github.io/docs/troubleshooting.html#npm-linked-modules-doesn-t-find-their-dependencies

Turning off symlink resolution also makes it so webpack can’t watch for changes in the linked dependency 😦 Any other solutions?

This issue should be reopened as it is not properly solved. A module that is linked cannot be debugged with symlinks disabled.

Yeah, what I do is usually npm i all dependencies of the package I’m linking to in the package I’m working on. Works like a charm.

Can we re-open this issue?

Actually I’m still having this problem, where I do npm link a-package to another one i’m working on. The symlink works fine but some dependencies inside that linked package don’t get resolved… It’s on Webpack": “4.8.3”.

Any ideas?

How is this issue still closed when the only solution is a noisy workaround?

@xthilakx that‘s not an option in the case HMR is needed where webpack needs to watch updates inside of the linked package. This is necessary when developing a library together with the client app.

#811 (comment)

@fabb I understand that it would be awesome to HMR from the linked package, but you should reconsider your development setup if symlinking packages are the only way for you to develop your lib locally.

I adapted @yuvke 's solution, making it sync and supporting scoped packages. See this gist for a webpack config example.

In my case following webpack config worked: for development mode - resolve: { modules: [path.resolve("./node_modules")] }, for production mode - resolve: { symlinks: false, modules: [path.resolve("./node_modules")] } Note, I have disabled babel for development and HMR. Also my imported module was in ES6 (not transpiled).

@xthilakx that‘s not an option in the case HMR is needed where webpack needs to watch updates inside of the linked package. This is necessary when developing a library together with the client app.

https://github.com/webpack/webpack/issues/811#issuecomment-317875352

@mesqueeb, I also still experienced this. Tried to play with the symlinks property but it didn’t help.

What I ended up doing is looking through the node_modules folder, and if a folder was in fact a symlink, I would add the resolved address + node_modules to the modules array.

For example something like this:

const path = require('path');
const projectPath = 'full/path/to/project'
const projectNodeModulesPath = path.resolve(projectPath, 'node_modules');
const modules = [ projectNodeModulesPath ];
    
await Promise.all((await fse.readdir(projectNodeModulesPath)).map(async el => {
    const modulePath = path.resolve(projectNodeModulesPath, el);
    if ((await fse.lstat(modulePath)).isSymbolicLink()) {
        const realModulePath = path.resolve(await fse.realpath(modulePath), 'node_modules');
        resolves.push(realModulePath);
    }
}));

@xthilakx don‘t get me wrong, I love developing my components with storybook, and I would keep doing so. HMR with storybook is much quicker than with my large app. I would just like to be able to quickly try out some changes of the components in my main app without releasing a package version. I use Verdaccio too, since we release our components only for internal use (not open source).

If you’re getting Error: Cannot find module X when using your linked module in webpack, make sure to build it before use (especially when freshly cloned to your local machine). It’s pretty trivial, but I got caught here.

Same here with webpack 2.x, using yarn link in my case

Same here with webpack 2.x, npm-link’ed modules hangs compilation…

for loaders the behavior was changed to webpack 2. They now resolve relative to the configuration file instead of relative to the affected module