React-transition-group: dom-helpers version mismatch

Created on 18 Sep 2019  路  12Comments  路  Source: reactjs/react-transition-group

What is the current behavior?

I have dependencies with dom-helpers 3.4
In upper level of node_modules I have 3.4 version.
It seems, that while bundling webpack search dom-helpers at root level node_modules/dom-helpers, but not inside node_modules/react-transition-group/node_modules/dom-helpers.
Should dom-helpers be in peer dependencies?

ERROR in ../node_modules/react-transition-group/esm/CSSTransition.js
Module not found: Error: Can't resolve 'dom-helpers/addClass' in '/Users/tasogare/Projects/sdc-repos/sdc/launcher/ui/node_modules/react-transition-group/esm'
 @ ../node_modules/react-transition-group/esm/CSSTransition.js 5:0-47 13:11-22
 @ ../node_modules/react-transition-group/esm/index.js
 @ ./containers/taxi/components/statusBar/index.js
 @ ./containers/taxi/components/layout/index.js
 @ ./containers/taxi/index.js
 @ ./containers/app/index.js
 @ ./index.js
 @ multi babel-polyfill ./index.js ./main.scss

ERROR in ../node_modules/react-transition-group/esm/CSSTransition.js
Module not found: Error: Can't resolve 'dom-helpers/removeClass' in '/Users/tasogare/Projects/sdc-repos/sdc/launcher/ui/node_modules/react-transition-group/esm'
 @ ../node_modules/react-transition-group/esm/CSSTransition.js 6:0-53 19:11-25
 @ ../node_modules/react-transition-group/esm/index.js
 @ ./containers/taxi/components/statusBar/index.js
 @ ./containers/taxi/components/layout/index.js
 @ ./containers/taxi/index.js
 @ ./containers/app/index.js
 @ ./index.js
 @ multi babel-polyfill ./index.js ./main.scss

What is the expected behavior?

Bundled succesfully.

Could you provide a CodeSandbox demo reproducing the bug?

Most helpful comment

@jquense You are right! The solution was to add the package local node_modules folder as well and remove the alias configuration:

resolve: {
    extensions: [".ts", ".tsx", ".js", ".json"],
    modules: [path.resolve(__dirname, "node_modules"), "node_modules"]
}

All 12 comments

No, it shouldn't be in peer deps. This is the problem with webpack resolver. Do you use webpack directly or with wrapper tool like gatsby or next?

No, it shouldn't be in peer deps. This is the problem with webpack resolver. Do you use webpack directly or with wrapper tool like gatsby or next?

directly
webpack 4

Same problem here, using [email protected] directly.

Show your configs guys. Also check this please
https://github.com/reactjs/react-transition-group/issues/550#issuecomment-530113747

Yes, it was absolute path for node_modules.
https://github.com/webpack/webpack/issues/6505#issuecomment-366502560

@jbreemhaar Check your config, you probably have same issue.

Same issue here in a Lerna monorepo. All other modules are found, just not these ones.

Works with defining aliases. But why is that needed?

resolve: {
    extensions: [".ts", ".tsx", ".js", ".json"],
    modules: [path.resolve(__dirname, "node_modules")],
    alias: {
      "dom-helpers/addClass": path.resolve(__dirname, "node_modules/dom-helpers/class/addClass"),
      "dom-helpers/removeClass": path.resolve(
        __dirname,
        "node_modules/dom-helpers/class/removeClass"
      )
    }
  },

@davthu this line: modules: [path.resolve(__dirname, "node_modules")], is breaking the normal node module resolution logic. Normally packages check for dependences close to themselves first, e.g deps they installed. but this is overriding it and telling all dependencies to check your specific node_modules first. If you have another version of dom-helpers in the root node_modules the package will use that, even tho it's the wrong version

@jquense You are right! The solution was to add the package local node_modules folder as well and remove the alias configuration:

resolve: {
    extensions: [".ts", ".tsx", ".js", ".json"],
    modules: [path.resolve(__dirname, "node_modules"), "node_modules"]
}

@davthu Does it work without this modules option?

@TrySound We have to use the modules option as mentioned above (with project root node_modules and package local node_modules). I got stuck because I thought Lerna was hoisting all modules to the root which might not be the case if we have different versions of dependencies.

"dom-helpers/addClass": path.resolve(__dirname, "node_modules/dom-helpers/class/addClass"),
"dom-helpers/removeClass": path.resolve(
__dirname,
"node_modules/dom-helpers/class/removeClass"
)

I had the same issue but in reverse, I got mine resolved following this.

Tried all of the above, but the error remains...

Was this page helpful?
0 / 5 - 0 ratings