Explicitly setting modulePathIgnorePatterns to the default value breaks dontMock method about jest

[madjam002]

I seem to be getting a problem similar to what you described with the following config:

  "jest": {
    "testDirectoryName": "test",
    "scriptPreprocessor": "test/.preprocessor.js",
    "testFileExtensions": [
      "coffee",
      "js"
    ],
    "moduleFileExtensions": [
      "coffee",
      "js"
    ]
  }

Calling jest.dontMock() seems to disable mocking on all require's, for example:

jest.dontMock '../src/service'

describe 'service', ->

  describe 'build', ->
    it 'should call the service builder', ->
      serviceBuilder = require '../src/service-builder'
      Service = require '../src/service'

serviceBuilder is my actual service builder instead of a mock, so I have to avoid using jest.dontMock and use require.requireActual instead.

I'm not sure whether these problems are related to your one, just thought I'd post about it here 😄

[lrowe]

I believe that the fix for #20 in 56c4f55 is incomplete as _getNormalizedModuleID will still return user:: for modules excluded from the resource map. While it does try to lookup the moduleResource:

    if (realAbsPath === null) {
      var moduleResource = this._getResource('JS', moduleName);
      if (moduleResource) {
        realAbsPath = moduleResource.path;
      }
    }

Here _getResource returns undefined. I believe this is because it only consults the Haste resourceMap, from which the file we're after has been explicitly excluded based on modulePathIgnorePatterns (which defaults to empty not "/node_modules/" as stated in the docs.)

Loader.prototype._getResource = function(resourceType, resourceName) {
  var resource = this._resourceMap.getResource(resourceType, resourceName);

  // TODO: Fix this properly in node-haste, not here :(
  if (resource === undefined && resourceType === 'JS' && /\//.test(resourceName)
      && !/\.js$/.test(resourceName)) {
    resource = this._resourceMap.getResource(
      resourceType,
      resourceName + '.js'
    );
  }

  return resource;
};

[messfromspace]

I have this issue with every module and not only with npm modules. So if I write something like this:

describe "Whatever", ->
  it "does something", ->
    jest.dontMock "../path/to/a"
    a = require "../path/to/a"
    b = require "../path/to/b"
    expect(a.mock).toBeUndefined()
    expect(b.mock).toBeDefined()

Test fails because b doesn't have mock property. So I need to use something like jest.mock "../path/to/b" or a = require.requireActual "../path/to/a" without dontMock to make it work as expected.

In my case dontMock is broken and disables mocks for every module.
Sorry for my bad English.

[aaronjensen]

For me, simply setting unmockedModulePathPatterns to the react suggested one:

    "unmockedModulePathPatterns": [
      "<rootDir>/node_modules/react"
    ],

seems to break jest.dontMock completely as well, in that nothing else auto mocks after that one dontMock. This seems like a pretty severe issue, I'm surprised many other haven't been hitting it.

[aaronjensen]

@messfromspace are you using coffeescript by chance for your other files? It seems like haste is not loading coffeescript files properly and therefore returning user:: as the module id for anything coffee... so when you dontmock one, it is the same as not mocking the others.

[pselden]

Just would like to note that the original bug (Explicitly setting modulePathIgnorePatterns to the default value breaks dontMock method) is likely a documentation issue. The real default for this is just an empty array. Ignoring the actual node_modules folder will completely break mocking (because it needs to load into haste to mock it).

[jacobstr]

@pselden In my experience, the bug interacts with testPathDirs as well.

testPathDirs

  A list of paths to directories that Jest should use to search for tests in.

  There are times where you only want Jest to search in a single 
  sub-directory (such as cases where you have a src/ directory in your repo),
  but not the rest of the repo.

^^ That sounds like it should only affect the discovery of test files.

It's an additionally painful ergonomics issue because the two settings look like ripe targets for improving Jest's poor startup time. And yes - excluding node_modules from testPathDirs does seem to make it run faster, but you've got this latent bug where the vaunted auto-mocking goes bonkers.

[gnesher]

Any intention on addressing this? been open for a while

[williamfligor]

I did some digging,

Setting modulePathIgnorePatterns causes Loader.prototype._getNormalizedModuleID in HasteModuleLoader.js to always return "user::" as the module id. This isn't a problem until you use dontMock and add an entry in HasteModuleLoader's this._explicitShouldMock. This entry looks like "user::": false.

When you require a module after using modulePathIgnorePatterns and using dontMock, the loader when it calls _shouldMock, always returns false because it calls _getNormalizedModuleID, which always returns "user::".

I think when using modulePathIgnorePatterns something goes wrong generating the resource map. Not sure though

Edit: Mocking started working again when I added "testFileExtensions": ["js", "jsx"], to my config

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.

[petejkim]

I am still experiencing this issue.

[Pharserror]

Not that I know of
On Sep 9, 2015 9:09 PM, "Peter Jihoon Kim" [email protected] wrote:

This is still a problem

—
Reply to this email directly or view it on GitHub
#66 (comment).

[AlcockP]

I'm seeing the same issue if I specify a testPathDirs ... even if it is "testPathDirs": ["__tests__"]

After removing that from my config, everything works fine.

[mzratio]

I have the exact same problem described by @AlcockP. Removing testPathDirs resolved the problem and everything is mocked properly.

[CodeBaboon]

+1 on the problem with testPathDirs. Replacing dontMock() with require.requireActual('path') seems to be a viable workaround.

[cpojer]

This should not be an issue any more with jest 0.7+.

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