Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

jest-resolve fails on network drives and RAM-drives on Windows #6880

Closed
asapach opened this issue Aug 23, 2018 · 21 comments · Fixed by #6925
Closed

jest-resolve fails on network drives and RAM-drives on Windows #6880

asapach opened this issue Aug 23, 2018 · 21 comments · Fixed by #6925

Comments

@asapach
Copy link
Contributor

asapach commented Aug 23, 2018

💥 Regression Report

Starting with jest@23 our tests started failing when using a RAM-drive on Windows (we are using a tool called ImDisk). The same can be reproduced when using a network drive (net use).

Last working version

Worked up to version: v22.4.4

Stopped working in version: v23.0.0

To Reproduce

Steps to reproduce the behavior:

  1. Follow the Getting Started guide and create a simple test suite
  2. Create a network drive e.g. net use x: \\localhost\c$\tmp
  3. Open the command line in x: and run yarn test / npm test

Expected behavior

Test suite should pass.

Actual behavior

Resolution fails with different kinds of errors, e.g.:

    Cannot find module 'source-map-support' from 'source-map-support.js'

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:221:17)

or

   EISDIR: illegal operation on a directory, realpath '...\node_modules\regenerator-runtime'

     at realpathSync (node_modules/realpath-native/index.js:25:32)

Run npx envinfo --preset jest

Paste the results here:

  System:
    OS: Windows 8.1
    CPU: x64 Intel(R) Core(TM) i5-4200M CPU @ 2.50GHz
  Binaries:
    Yarn: 1.7.0 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 5.6.0 - C:\Program Files\nodejs\npm.CMD
@asapach
Copy link
Contributor Author

asapach commented Aug 23, 2018

The issue was introduced in #5085. If I roll it back it works fine.
My understanding is that fs.realPath() uses a more modern API on Windows (GetFinalPathNameByHandle()), which is not supported by older drivers.

Is it possible to hide the symlinks resolution logic behind an option e.g. followSymlinks (enabled by default) so that the old behavior would be preserved?

(CC @nickpape-msft)

@SimenB
Copy link
Member

SimenB commented Aug 24, 2018

None on the team uses Windows, so I'm afraid this won't be fixed without help from the community. I'm also unsure what the correct solution would be, if to fix your issue we have to rollback a fix to another one...

@asapach
Copy link
Contributor Author

asapach commented Aug 24, 2018

I'm not proposing to roll it back, I'd prefer to have an option that would allow to switch between the two modes. I can create a PR if that's OK.

@SimenB
Copy link
Member

SimenB commented Aug 24, 2018

Having an option for this in jest's config should be the last resort, I think. I suppose we could add it as an option to jest-resolve and then you could set up a custom resolver in your project

@asapach
Copy link
Contributor Author

asapach commented Aug 24, 2018

Yes, sorry, I meant jest-resolve options. We're already using a custom resolver in our project, so that should work fine.

@SimenB
Copy link
Member

SimenB commented Aug 24, 2018

PR for that would be most welcome :)

@asapach
Copy link
Contributor Author

asapach commented Aug 24, 2018

@SimenB I'm almost there (I've got a fork ready: https://github.com/asapach/jest/tree/symlinks), but I got stuck. I can create a custom resolver and pass my options, but there's a root resolver created in jest-runtime and I can't pass any extra options there unless I add them to ProjectConfig:
https://github.com/facebook/jest/blob/c4007d7bc6b6b97c2016af5872b461c2e85ce4ac/packages/jest-runtime/src/index.js#L250-L261

It does not delegate to custom resolver and fails here:
https://github.com/facebook/jest/blob/c4007d7bc6b6b97c2016af5872b461c2e85ce4ac/packages/jest-runtime/src/index.js#L588

Do you have any suggestions how to work around that? Any help is appreciated.

@SimenB
Copy link
Member

SimenB commented Aug 27, 2018

Auch... @thymikee thoughts? I'm not familiar with this part of the code base

@thymikee
Copy link
Collaborator

I guess we'll need to add a new project option followSymlinks for that.

@asapach
Copy link
Contributor Author

asapach commented Aug 27, 2018

I took a look and I think it's not feasible to pass the option correctly to every resolve call. This would affect jest-config, jest-resolve and jest-runtime. I'll probably abandon this route.

I have an alternative proposal: we could call fs.lstatSync() and stats.isSymbolicLink() before calling realpath():
https://github.com/facebook/jest/blob/c93e02718480b9f25b0d28f33456ed159bd11b69/packages/jest-resolve/src/node_modules_paths.js#L44-L52
That would verify that realpath is resolved only for symbolic links, which solves the issue as well.
What do you guys think?

@thymikee
Copy link
Collaborator

How would that affect resolve performance?

@asapach
Copy link
Contributor Author

asapach commented Aug 27, 2018

"Happy path" should not be different - one realpath.native call will be replaced by lstat call (which is probably faster).
"Symlink path" would incur two calls, but that should be relatively rare.
Do you guys run benchmarks to compare the results?

@thymikee
Copy link
Collaborator

We don't have a special suite for that. Usually checking on Jest, React, maybe Webpack codebase. Also @mjesun and @aaronabramov make sure everything runs smoothly on FB, so you can ask them to test your diff

@asapach
Copy link
Contributor Author

asapach commented Aug 27, 2018

OK, thanks. I'll get the PR ready tomorrow.

@gsteacy
Copy link

gsteacy commented Aug 27, 2018

I'm interested to test this as well, though I may not get a chance for a few days. #5085 had a measurable negative impact on performance so I'd be concerned about adding even more overhead. However, I'd also be pleased if overhead was reduced. :)

@asapach
Copy link
Contributor Author

asapach commented Aug 28, 2018

As promised, here's the PR: #6906

@webuniverseio
Copy link

I was getting

 Cannot find module 'source-map-support' from 'source-map-support.js'

      at Resolver.resolveModule (node_modules/jest-resolve/build/index.js:221:17)

Changing

"moduleDirectories": ["/node_modules/"],

to

"moduleDirectories": ["node_modules"],

fixed the issue

@ivancuric
Copy link

ivancuric commented Feb 27, 2019

Haven't managed to get it working. Any updates on this?

I'm running babel 7.
My jest.config.js looks like this:

module.exports = {
  testEnvironment: 'node',
  roots: ['<rootDir>/src'],
  testRegex: '(/__tests__/.*|(\\.|/)(test|spec))\\.tsx?$',
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
  collectCoverageFrom: ['src/**/*.{ts,tsx}'],
  clearMocks: true,
  setupFilesAfterEnv: ['<rootDir>/src/setupEnzyme.ts'],
  moduleNameMapper: {
    '\\.(gif|ttf|eot|svg)$': '<rootDir>/__mocks__/fileMock.js',
  },
};

And my .babel.config.js is

module.exports = {
  presets: [
    [
      '@babel/preset-env',
      {
        targets: {
          node: 'current',
        },
      },
    ],
    '@babel/preset-typescript',
  ],
  plugins: [
    '@babel/proposal-class-properties',
    '@babel/proposal-object-rest-spread',
  ],
};

When running either jest --rootDir . or jest, I'm getting the following error:

● Validation Error:

  Module ts-jest in the transform option was not found.
         <rootDir> is: \\Mac\Home\Dev\

With a minimal setup like

module.exports = {
  testEnvironment: 'node',
  transform: {
    '^.+\\.(js|jsx|ts|tsx)$': 'babel-jest',
  },
  moduleDirectories: ['node_modules', 'src'],
  testRegex: '(/__tests__/.*|(\\.|/)(test|spec))\\.tsx?$',
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
};

I get

FAIL  src/ui/crashDump.test.ts
  ● Test suite failed to run

    Cannot find module 'source-map' from 'source-map-support.js'

      at Resolver.resolveModule (Z:/Dev/***/node_modules/jest-resolve/build/index.js:203:17)
      at Object.<anonymous> (node_modules/source-map-support/source-map-support.js:1:114)

@rahulcyadav
Copy link

facing this issue...what is the solution?

@avgalon
Copy link

avgalon commented Mar 25, 2020

I too have this problem.
I get this(F is a ram drive on win10):
Error: EISDIR: illegal operation on a directory, realpath 'F:_work\2\s\client'
at Function.realpathSync.native (fs.js:1521:3)
at realpathSync (F:_work\2\s\client\node_modules\realpath-native\index.js:29:28)
at Object. (F:_work\2\s\client\node_modules\jest-resolve\build\index.js:85:48)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
jest config:

module.exports = {
  reporters: [
    "default",
    [
      "jest-junit",
      {
        outputDirectory: "<rootDir>"
      }
    ]
  ],
  coverageReporters: [
    "text",
    "cobertura"
  ],
  preset: "jest-preset-angular",
  setupFilesAfterEnv: ["<rootDir>/src/setupJest.ts"],
  cacheDirectory: '<rootDir>/.cache',
  testMatch: ['<rootDir>/src/app/**/*.spec.ts'],
  testPathIgnorePatterns: ['<rootDir>/node_modules', '<rootDir>/vendors'],
  transform: {
    '^.+\\.ts?$': 'ts-jest',
    '^.+\\.scss?$': 'jest-transform-css'
  },
  collectCoverage: true,
  modulePathIgnorePatterns: ['<rootDir>/src/mocks/*/*.mock.ts'],
  transformIgnorePatterns: [
    "node_modules/(?!@cellebrite/ui-components)"
  ],
  globals: {
    'ts-jest': {
      tsConfig: '<rootDir>/src/tsconfig.spec.json',
      stringifyContentPathRegex: '\\.html$',
      astTransformers: ['jest-preset-angular/InlineHtmlStripStylesTransformer.js']
    }
  }
};

@github-actions
Copy link

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
8 participants