Webpack dependencies fail with npm linked package.

[trusktr]

My project depends on a package that works perfectly when installed normally, but when I npm link that package for local development, webpack fails finding dependencies like so:

[14:38:15] Version: webpack 1.5.3
                      Asset     Size  Chunks             Chunk Names
    tcc-ip-client.bundle.js  2690831       0  [emitted]  client
tcc-ip-client.bundle.js.map  3223307       0  [emitted]  client

ERROR in ../blah/src/js/utils/features.js
Module not found: Error: Cannot resolve module 'foobar/src/js/utils/endpoint' in /Users/josephpea/src/blah/src/js/utils
 @ ../blah/src/js/utils/features.js 10:0-109:2

[trusktr]

100% certain these errors happen only after I've npm linked that package in the project.

[trusktr]

Any info I can provide? I can't really provide access to the repo I'm linking because it's internal/private, but maybe there's some useful specific info I can provide?

[sokra]

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

[trusktr]

Ah, ok. Thanks!! I would've had no idea!

[trusktr]

@sokra This problem isn't intuitive at all. For example, it just happened to me again: krasimir/cssx#15. I think a solution is needed.

[sokra]

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

[sokra]

also related #2937

[SpaceK33z]

Closing this since it appears to have been fixed in webpack 2. @trusktr, if you still have this issue in webpack 2, please re-open.

[MatteoWebDeveloper]

Hi I am using webpack 2 and I cannot figure out why I am having this issue:

ERROR in ./src/index.js
Module not found: Error: Can't resolve 'webpack-test-import' in '/user/test-webpack/src'
@ ./src/index.js 7:25-55
@ multi (webpack)-dev-server/client?http://localhost:8080 webpack/hot/dev-server ./index.js

here the webpack config

import path from 'path';
import HtmlWebpackPlugin from 'html-webpack-plugin';

export default {
    context: path.resolve(__dirname, 'src'),
    entry: './index.js',
    output: {
        path: path.resolve(__dirname, 'build'),
        filename: 'bundle.js',
        chunkFilename: 'bundle-[id].js'
    },
    module: {
        rules: [{
            test: /\.js$/,
            exclude: /node_modules/,
            use: {
                loader: 'babel-loader',
                options: {
                    cacheDirectory: 'cache/'
                }
            }
        }]
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: './index.html',
            minify: {
                collapseWhitespace: true
            }
        }),
    ],
    devtool: "cheap-eval-source-map",
    devServer: {
        contentBase: path.join(__dirname, "build"),
        compress: true,
        port: 8080,
        open: true
    }
};

index.js

import internalModule from './module.js';
import externalModule from 'webpack-test-import';

console.log('internal import, ' + internalModule);

[septagram]

@SpaceK33z no it's not fixed, having the same problem here.

ERROR in ../react-calendar-component/lib/Calendar.js
Module not found: Error: Can't resolve 'react' in 'd:\Dropbox\Code\react-calendar-component\lib'

Worse yet, the workaround doesn't work anymore:

Invalid configuration object. Webpack has been initialised using a configuration object that does not match the API schema.
 - configuration.resolve has an unknown property 'fallback'. These properties are valid:
   object { alias?, aliasFields?, cachePredicate?, descriptionFiles?, enforceExtension?, enforceModuleExtension?, extensions?, fileSystem?, mainFields?, mainFiles?, moduleExtensions?, modules?, plugins?, resolver?, symlinks?, unsafeCache?, useSyncFileSystemCalls? }
 - configuration.resolveLoader has an unknown property 'fallback'. These properties are valid:
   object { alias?, aliasFields?, cachePredicate?, descriptionFiles?, enforceExtension?, enforceModuleExtension?, extensions?, fileSystem?, mainFields?, mainFiles?, moduleExtensions?, modules?, plugins?, resolver?, symlinks?, unsafeCache?, useSyncFileSystemCalls? }

[damianobarbati]

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

[miketeix]

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

[erquhart]

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.

[thescientist13]

thanks @erquhart , that helped resolve the issue for me!

[joaoreynolds]

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

[mesqueeb]

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?

[yuvke]

@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);
    }
}));

[mesqueeb]

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?

[diachedelic]

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

[ralyodio]

@diachedelic that doesn't work for me, same error.

[diachedelic]

@chovy could you try printing the results of findLinkedModules to console, and comparing it with the pathname in the error message?

[ralyodio]

i goofed. i didn't know i had to build the library first. now it works fine w/o any changes.

[victmo]

@diachedelic solution worked for me as well

[raffomania]

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

[thilak-rao]

@raffomania Set resolve.symlinks to false. By default, it's set to true in webpack4.

https://webpack.js.org/configuration/resolve/#resolve-symlinks

[fabb]

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

[J-Rojas]

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

[evenfrost]

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.

[senikiti]

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).

[thilak-rao]

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

[fabb]

@xthilakx I want to develop my lib together with my main app in tandem because it would be faster to get all the requirements right. I can develop the library on its own, and I have Storybook and jest there, but when developing new features for my app, it‘s easy to forget about an edge case, and then I have to build another package version with the fix. And yes, I already have building a new package version optimized to a single click, but it‘s still another roundtrip and takes time to build and then install in my app.

[thilak-rao]

@fabb I have exactly the same setup as you (Storybook/Jest), but I do not develop my components with projects symlinked using npm link. Of course, it is important to test it end to end before you ship your code or publish it to npm registry, but you can do that during the testing phase (before you commit your changes)

Symlinking has other quirks too, such as this, so I use verdaccio as a local npm registry for testing.

Symlinking to develop locally defeats the purpose of using tools like Storybook, IMHO.

[fabb]

@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).