Resolving peer modules when using local linked packages #2447

voliva · 2016-12-27T13:39:51Z

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
Having the following structure:

- MyModule
  | - MyDependency
  | - MyLibrary
    | - MyDependency

When MyLibrary requires MyDependency, it loads it from MyModule/node_modules/MyLibrary/node_modules folder if it's available, when it should get the peer version.
The problem that this issue arises is an inconsistent behaviour when using local linked packages, because when installing through yarn install MyLibrary won't contain a node_modules folder, but when doing through yarn link MyLibrary it will, as it's a soft link.

In my case, MyDependency is rx, and MyLibrary creates a Reactive extension by defining some methods on Rx.Observable.prototype. When running jest without any local link, or when through nodejs, this works properly, but when running through jest with MyLibrary locally linked, Rx.Observable.prototype gets wiped when rx is loaded a second time.

If the current behavior is a bug, please provide the steps to reproduce and a minimal repository on GitHub that we can yarn install and yarn test.
https://github.com/voliva/jestpeer
You must locally link the modules by:

> cd MyDep; yarn link; cd ..
> cd MyLib; yarn link MyDep; yarn link; cd ..
> cd MyModule; yarn; yarn link MyDep; yarn link MyLib;

If you run yarn start, that's just node running the app, you should get:

MyDep run/load C:\Users\victor\Documents\development\jestpeer\MyDep
MyLib run/load C:\Users\victor\Documents\development\jestpeer\MyLib
MyModule run/load C:\Users\victor\Documents\development\jestpeer\MyModule
Done in 0.27s.

If you run yarn test, that's jest running the test, you should get:

Ran all test suites.
  console.log node_modules\MyLib\node_modules\MyDep\index.js:1
    MyDep run/load C:\Users\victor\Documents\development\jestpeer\MyModule\node_modules\MyLib\node_modules\MyDep

  console.log node_modules\MyLib\index.js:3
    MyLib run/load C:\Users\victor\Documents\development\jestpeer\MyModule\node_modules\MyLib

  console.log node_modules\MyDep\index.js:1
    MyDep run/load C:\Users\victor\Documents\development\jestpeer\MyModule\node_modules\MyDep

  console.log index.js:4
    MyModule run/load C:\Users\victor\Documents\development\jestpeer\MyModule

Done in 3.23s.

Notice how while when running through node MyLib doesn't get loaded twice, while when running through Jest it does

What is the expected behavior?
yarn test should output

Ran all test suites.
  console.log node_modules\MyDep\index.js:1
    MyDep run/load C:\Users\victor\Documents\development\jestpeer\MyModule\node_modules\MyDep

  console.log node_modules\MyLib\index.js:3
    MyLib run/load C:\Users\victor\Documents\development\jestpeer\MyModule\node_modules\MyLib

  console.log index.js:4
    MyModule run/load C:\Users\victor\Documents\development\jestpeer\MyModule

Done in 3.23s.

Please provide your exact Jest configuration and mention your Jest, node, yarn/npm version and operating system.
Default jest configuration, Jest 18.0.0, node 6.9.1, yarn 0.19.0, Windows 10 64bit.

The text was updated successfully, but these errors were encountered:

voliva · 2016-12-27T13:41:20Z

When debugging, I found the logic where modules get resolved is in Jest's build\index.js _normalizeID(from, moduleName)

thymikee · 2016-12-27T13:43:18Z

Just curious – have you tried linking with npm instead of yarn?

voliva · 2016-12-27T13:47:40Z

@thymikee Just tried and still having the same issue... Npm version 3.10.8

L8D · 2017-01-19T15:50:28Z

👍 I'm having the same problem when running tests against packages linked via lerna. I believe it prevents tracking coverage of linked packages as well.

L8D · 2017-01-19T16:55:25Z

@voliva @thymikee I just figured out this is a bug in the node-resolve package. I have a PR for a fix that seems to fix all the problems I've had with jest & linked packages here.

To fix temporarily, you can add an npm-shrinkwrap.json that overrides the version of resolve with my patched version.

{
  "dependencies": {
    "browser-resolve": {
      "version": "1.11.2",
      "from": "browser-resolve@>=1.11.2 <2.0.0",
      "resolved": "https://registry.npmjs.org/browser-resolve/-/browser-resolve-1.11.2.tgz",
      "dependencies": {
        "resolve": {
          "version": "https://s3.amazonaws.com/waldo-public/resolve-1.2.0-patched.tar.gz",
          "from": "[email protected]",
          "resolved": "https://s3.amazonaws.com/waldo-public/resolve-1.2.0-patched.tar.gz"
        }
      }
    },
    "resolve": {
      "version": "https://s3.amazonaws.com/waldo-public/resolve-1.2.0-patched.tar.gz",
      "from": "resolve@>=1.2.0 <2.0.0",
      "resolved": "https://s3.amazonaws.com/waldo-public/resolve-1.2.0-patched.tar.gz"
    }
  }
}

chrbala · 2017-03-19T07:32:53Z

@L8D have you had any progress with getting your fix merged?

batzlerg · 2017-04-27T16:23:39Z

Until this is fixed, a workaround is to add a jest config remapping references to the linked module to the parent version.

In MyModule/package.json:

"jest": {
    "moduleNameMapper": {
        "^MyDep$": "<rootDir>/node_modules/MyDep"
    }
}

This produces the expected output in @voliva's test repo.

kebot · 2019-01-16T11:39:46Z

Another solution will be:

"moduleDirectories": [
      "<rootDir>/node_modules",
      "node_modules"
],

And I might open a pull request to make it default behaviour

SevenZark · 2019-11-29T16:00:10Z

Sorry, but I'm curious why this was closed? Was there a resolution? Because I'm having this issue with jest 24.9.0 and have tried every solution suggested in this thread. Nothing works. My linked module can't find @material-ui/core within a jest test (but no problems when running it linked in the linked app). Have we just given up on doing this? If so, this makes Jest useless to me.

matheo · 2020-01-11T21:31:58Z

@SevenZark the moduleNameMapper and moduleDirectories solution worked for me with [email protected], I kept just the moduleDirectories to avoid further issues without needing to map every lib I have inside linked modules.

SevenZark · 2020-01-12T16:33:22Z

@SevenZark the moduleNameMapper and moduleDirectories solution worked for me with [email protected], I kept just the moduleDirectories to avoid further issues without needing to map every lib I have inside linked modules.

Apologies, I neglected to mention something very important, which is that I'm using create-react-app and therefore cannot alter things with moduleNameMapper. I realize that's a big omission.

Jest tests fail locally when `yarn link` points to a lib with peer dependencies. This map configuration adds redirection to import these dependencies from <rootDir>/node_modules instead of the linked modules folders. jestjs/jest#2447 (comment)

leejh3224 · 2021-10-01T03:14:50Z

#2447 (comment)

Just out of curiosity, what's the purpose of starting and ending signs? (I mean ^ and $ in moduleNameMapper config)

For some context, I had failing tests with the following settings.

...
moduleNameMapper: {
    'mongoose': '<rootDir>/node_modules/mongoose',
    ...
},
...

Output looked like the below.

Test suite failed to run

    TypeError: Class extends value [object Object] is not a constructor or null

      1 | import { Injectable } from "@nestjs/common"
    > 2 | import { InjectModel } from "@nestjs/mongoose"
        | ^

      at Object.<anonymous> (node_modules/mongoose/lib/error/notFound.js:10:37)
      at Object.<anonymous> (node_modules/mongoose/lib/error/index.js:79:39)
      at Object.<anonymous> (node_modules/mongoose/lib/document.js:9:23)
      at Object.<anonymous> (node_modules/mongoose/lib/index.js:18:18)
      at Object.<anonymous> (node_modules/mongoose/index.js:9:18)

Then I changed my setting into

...
moduleNameMapper: {
    '^mongoose$': '<rootDir>/node_modules/mongoose',
    ...
},
...

All of a sudden, tests passed as if nothing has happened.

Does anyone knows the difference between moduleName and ^moduleName$ in the context of moduleNameWrapper setting?

SimenB · 2021-10-01T07:21:41Z

It's a regex: https://en.wikipedia.org/wiki/Regular_expression#POSIX_basic_and_extended

SimenB · 2021-10-01T07:25:57Z

That said, this is a really old issue and the linked reproduction in the OP is deleted, so I'll close this.

If the fix in #2447 (comment) is correct, then this issue is fixed as we do call realpath on the resolved files: #9511 (https://github.com/facebook/jest/blob/c3b0946a639e64b76387ae979249d52df7cfe262/packages/jest-resolve/src/defaultResolver.ts#L53).

If there are still problems with this, please open up a new issue with a reproduction

github-actions · 2021-11-01T00:04:54Z

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

voliva changed the title ~~Resolving peer modules when used local linked packages~~ Resolving peer modules when using local linked packages Dec 27, 2016

KyleAMathews mentioned this issue May 23, 2017

[1.0] Small fixes gatsbyjs/gatsby#1025

Merged

ahashem mentioned this issue Aug 23, 2019

Uncaught Error: Trying to insert a new style tag, but the given Node is unmounted! styled-components/styled-components#2008

Closed

csm-thu mentioned this issue May 3, 2021

Add map of module references for dependencies of linked modules Cosmo-Tech/azure-sample-webapp#14

Merged

SimenB closed this as completed Oct 1, 2021

github-actions bot locked as resolved and limited conversation to collaborators Nov 1, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Resolving peer modules when using local linked packages #2447

Resolving peer modules when using local linked packages #2447

voliva commented Dec 27, 2016 •

edited

Loading

voliva commented Dec 27, 2016

thymikee commented Dec 27, 2016

voliva commented Dec 27, 2016

L8D commented Jan 19, 2017

L8D commented Jan 19, 2017

chrbala commented Mar 19, 2017

batzlerg commented Apr 27, 2017

kebot commented Jan 16, 2019 •

edited

Loading

SevenZark commented Nov 29, 2019

matheo commented Jan 11, 2020 •

edited

Loading

SevenZark commented Jan 12, 2020 •

edited

Loading

leejh3224 commented Oct 1, 2021 •

edited

Loading

SimenB commented Oct 1, 2021

SimenB commented Oct 1, 2021 •

edited

Loading

github-actions bot commented Nov 1, 2021

Resolving peer modules when using local linked packages #2447

Resolving peer modules when using local linked packages #2447

Comments

voliva commented Dec 27, 2016 • edited Loading

voliva commented Dec 27, 2016

thymikee commented Dec 27, 2016

voliva commented Dec 27, 2016

L8D commented Jan 19, 2017

L8D commented Jan 19, 2017

chrbala commented Mar 19, 2017

batzlerg commented Apr 27, 2017

kebot commented Jan 16, 2019 • edited Loading

SevenZark commented Nov 29, 2019

matheo commented Jan 11, 2020 • edited Loading

SevenZark commented Jan 12, 2020 • edited Loading

leejh3224 commented Oct 1, 2021 • edited Loading

SimenB commented Oct 1, 2021

SimenB commented Oct 1, 2021 • edited Loading

github-actions bot commented Nov 1, 2021

voliva commented Dec 27, 2016 •

edited

Loading

kebot commented Jan 16, 2019 •

edited

Loading

matheo commented Jan 11, 2020 •

edited

Loading

SevenZark commented Jan 12, 2020 •

edited

Loading

leejh3224 commented Oct 1, 2021 •

edited

Loading

SimenB commented Oct 1, 2021 •

edited

Loading