moduleNameMapper does not work with `constants`

[maksimsemenov]

🐛 Bug Report

When I'm trying to use moduleNameMapper to resolve import from constants local folder, it does not work. It works fine, when I use singular form: constant.
I think it might happen because constants is sort of reserved module in node.js. However, plural form (constants) works fine with web pack aliases, so they find a workaround somehow.

To Reproduce

In one of the files import variable from constants module:

import { A_CONSTANT } from 'constants'

Set up an alias with moduleNameMapper:

"moduleNameMapper": {
      "^constants$": "<rootDir>/src/constants/index.js"
    }

Run tests

Expected behavior

The variable should be defined. Instead it is undefined

Link to repl or repo (highly encouraged)

https://github.com/maksimsemenov/jest-module-name-mapper

Run npx envinfo --preset jest

System:
    OS: macOS 10.14.5
    CPU: (4) x64 Intel(R) Core(TM) i5-4260U CPU @ 1.40GHz
  Binaries:
    Node: 10.15.3 - /opt/local/bin/node
    Yarn: 1.15.2 - /opt/local/bin/yarn
    npm: 6.9.0 - /usr/local/bin/npm
  npmPackages:
    jest: ^24.8.0 => 24.8.0 

[nishantnaagnihotri]

I am facing this issue too.

The alias 'constants' does not work with Jest.
Any import from this alias comes as undefined during tests.

Jest: 23.6.0

[SimenB]

Woah, this issue is super weird! The reason is that constants is a node core module

$ node -p "require('module').builtinModules.includes('constants')"
true

In that case, we give you that instead of the mapped module: https://github.com/facebook/jest/blob/94067089dd25c77463e24e981fe979fb6cc0b2fb/packages/jest-runtime/src/index.ts#L313-L315

I'm not sure how we should deal with this. We currently match node's behavior (even if you install e.g. fs from npm, doing require('fs') will silently give you the core module). Could we possibly throw an error if we resolve a local module, but figure out it's a node builtin?

/cc @thymikee @jeysal thoughts?

semi-related: nodejs/node#26012

[maksimsemenov]

I think that the main confusion point, at least for me, was that I can normally use constants with webpack aliases, they resolve it to local modules instead of node builtin. Not sure which approach is more correct, but webpack's is more convenient: I can put all my constants in one folder and easily access them.

[jeysal]

Intuitively, I'd assume moduleNameMapper overrides every aspect of the normal resolution like apparently it does in webpack, disregarding kinds of modules. And why not - if you want to use the respective core module in the same project, then ... umm, just don't configure the module name mapping like that 😅

[lh0x00]

I suggest to add new field in the config with name is node and implement like webpack config but exclude mock value, only support: true, false and empty. This config will be used in _requireCoreModule function. If you think it is a good idea, I can help! :D

[jeysal]

I don't think we need config for this, I think it should just be changed (fixed IMO). It should apply to module names like constants just like to any other module name.