Plan for multiple module systems

[iamdustan]

We’re getting ready to start a few projects where I would like to use jest heavily. The inability to hijack the module resolution calls is a bit prohibitive at the moment though. I would like to propose a simple plan to open up jest to module systems besides Haste.

• Refactor HasteModuleLoader to the core API and the HasteModuleLoader specifics
• Move HasteModuleLoader to it’s own npm package jest-haste
• Use HasteModuleLoader by default with jest (backwards compatibility)
• Allow config option for specific module loader (jest-webpack, jest-requirejs, etc)

Is there anything I’m completely neglecting or unaware of in this plan?

[blainekasten]

+1. This is a huge pain currently.

[mwolson]

Here's a workaround which can resolve webpack paths in the preprocess phase: https://www.npmjs.com/package/jest-webpack-alias

[cpojer]

I'm going to start rewriting the haste module loader soon and want to support third-party module loaders as outlined in this plan above. @iamdustan let me if there is anything I can do to support you better with the new functionality. Is adding a config for a different module loader enough for you?

[cpojer]

There is a moduleLoader config already that allows you to specify a custom module loader. Is that enough for most cases?

[iamdustan]

Sooooo I’m on to a different company and not using Jest anymore.

[cpojer]

What, you accepted a new job and didn't check with me first?

[iamdustan]

Weeeelllll buy me a house in a London suburb and I'll come work with you kind of sort of. (Not moving to California) 😇

[akheron]

Will the HasteModuleLoader rewrite fix the issue that it doesn't currently seem to understand how nodejs finds modules? If, for example, there are multiple files called foo.js somewhere under node_modules, only the last one found remains in resourceMap, and all require('foo') calls get that module. I'm not exactly sure why the resource id is resolved as foo for some foo.js files and path/to/foo.js for others, though.

In my case, this is a problem because I have node_modules/react-side-effect/node_modules/fbjs/flow/include/warning.js and node_modules/react-router/node_modules/warning/warning.js. When react-router calls require('warning') it gets the wrong warning.js, which happens to use ES6 syntax that's not supported by Node, and I'm getting a test failure due to SyntaxError.

[cpojer]

@akheron I suggest using a preprocessor to compile your code to ES5 before running test. Look at the babel-jest npm module.

@amasad can you elaborate on how the new dependency resolver resolves modules in this case?

[amasad]

So there are two issues here:

1. @providesModule being a single namespace (which is what fbjs uses). That means that require('warning') will get the last one node-haste managed to look at last. 😷
2. node-haste not supporting recursive node dependencies: when you have two foo node_modules, in different parts of the tree it will also pick one at random 😫

The react-native-packager resolver we're gonna base this off will solve these two issues by:

1. Doesn't allow node_modules to reach into the @providesModule namespace
2. will support recursive deps

[akheron]

@cpojer I use babel-jest, but the module with ES6 syntax is an external dependency. Furthermore, the file with ES6 syntax is not even used by the dependent library itself, it's just non-precompiled source that is shipped for reference.

@amasad I'm very happy to hear that I'm not the only one having this problem and that it's being fixed 👍

[cpojer]

you can still transform this file, you might have to update some configs but you can compile node_modules if you want.

[cpojer]

This work was completed in #599. Yay!

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