Jest resolver does not follow symbolic links

[difelice]

I have the following tree:

.
├── app_modules
│   ├── actions
│   ├── components
│   ├── __tests__
│   ├── constants
│   ├── libs
│   ├── models
│   ├── shared -> ../../../../../js_lib/shared/
│   │   ├── components
│   │   │   └── __tests__
│   │   ├── libs
│   │   └── utils
│   └── utils
└── src
    └── main

When running npm test all tests inside the symbolic link shared are not executed by the client.

Thank you.

[cpojer]

This is a deliberate design decision because symlinks always cause trouble. I recommend you to use the moduleNameMapper config option. See facebook.github.io/jest/docs/api.html#content

[difelice]

Does moduleNameMapper resolve the testPathDirs?

My issue is with test files not modules, when I run npm test from my rootDir, any test inside the symbolic link are not found:

.
├── app_modules
│   ├── actions
│   ├── components
│   ├── __tests__
│   ├── constants
│   ├── libs
│   ├── models
│   ├── shared -> ../../../../../js_lib/shared/
│   │   ├── components
│   │   │   └── __tests__  <- jest does not run tests in this folder
│   │   ├── libs
│   │   └── utils
│   └── utils
└── src
    └── main

Adding the folder <rootDir>/app_modules/shared/components/__tests__ in the testPathDirs works fine, but not <rootDir>/app_modules/shared, ideally it should start resolving the symbolic link if added in testPAthDirs.

Thanks.

[cpojer]

I recommend trying to use jest@test which is gonna be the next release of Jest.

[difelice]

I'll try it, thank you so much.

[difelice]

Do you mean npm i jest@latest? or npm i jest@test?

[mark0978]

I understand that you don't like symlinks, however I don't follow why you would block using them within the tool. Anyone that doesn't want to use symlinks doesn't have to, they just don't create them, but for you to disallow symlinks within the test finder makes our setup very hard to work with, especially since all the other tools we use are completely happy with symlinks.

Our setup looks like

+- ProjectA
     +- node_modules
     +- shared(symlink)--+   
+- shared               <+ <+
+- ProjectB                 |
     +- node_modules        |
     +- shared(symlink)-----

All the code shared between the 2 projects is in the real shared folder and both projects use a symlink to place that folder into both projects.

ProjectA is the main website, ProjectB is the admin website, so the shared folder is used extensively by both projects. What I've shifted to is:

+- ProjectA
     +- node_modules
     +- shared(symlink)-----+   
+- ProjectB                 |
     +- node_modules        |
     +- shared         <----+

Which will work, but is less obvious than the original layout. All because one tool (jest) has decided that symlinks "always cause trouble", something I would debate is false. So while it might be by design, does that design actually make sense in light of the rest of the toolchain which works just fine with symlinks?

[cpojer]

I think everything is working just fine in Jest, except for locating test files, which imho is a reasonable trade-of for what we are doing inside of jest's haste map.

[mark0978]

So, even though all the other tools work with symlinks, since you don't like symlinks, its perfectly acceptable for jest to explicitly ignore symlinks? Is that what you are saying?

[cpojer]

Feel free to send us a pull request that fixes Jest to fit your use case. If it doesn't make Jest harder to maintain and works within our constraints, I'm happy to accept it.

Personally, the only reason I get to work on Jest at Facebook is because I'm solving Facebook's problems related to JavaScript testing. This is not a problem for us so I'm not able to justify working on it myself.

[aleclarson]

@cpojer Do you think it would be easier to implement symlink support for node_modules only (instead of supporting any arbitrary symlink)? Any pointers would be great.

[cpojer]

no, I think it would make sense to support them overall. I think if you change the node crawler to support them behind a flag (that would disable watchman as well), I wouldn't stop you from adding it to the codebase, granted it is well written and tested etc.

[viddo]

Created a PR to solve this #4387, I'd appreciate some feedback over there.

[davesidious]

Is there any interest in this still? Having the ability to configure Jest to follow symlinks would make life in the monorepo world a lot easier. Currently each of our packages needs its own copy of a global __mocks__ directory, and symlinking it in during postinstall works perfectly. I'd love to add all the entries to the moduleNameMapper for each package but this list will grow large and have to be manually curated across all the packages.

[davesidious]

After lots of experimenting and digging through docs, it appears one can use the roots configuration option to specify multiple directories, which are included when looking for __mocks__. This solves my problem wonderfully.

[difelice]

@davesidious thanks for sharing your solution. Works on our project too.

[davesidious]

@difelice I'm glad I could help!

[majelbstoat]

Yeah, I'm working with a monorepo too, and lack of symlink support is a real pain.

[goranovs]

Any update here?

[SimenB]

#7549

[github-actions]

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.