jest: [Bug]: 27.x `requireOutside` broke `vscode-jest`

Version

27.2

Steps to reproduce

clone https://github.com/connectdotz/vscode-jest/tree/upgrade-dep
open vscode for the directory
yarn install
build extension: vsce package --yarn
load the extension directly from the file built from above: “vscode-jest-4.1.2.vsix”

Expected behavior

should work like 26.x

Actual behavior

vscode failed to load extension with the following error in the developer console:

mainThreadExtensionService.ts:95 Activating extension 'Orta.vscode-jest' failed: Cannot find module '@babel/traverse'
Require stack:
- /Users/vsun/.vscode/extensions/orta.vscode-jest-4.1.2/out/extension.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/vs/loader.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap-amd.js
- /Applications/Visual Studio Code.app/Contents/Resources/app/out/bootstrap-fork.js.

Additional context

@SimenB We are trying to upgrade vscode-jest and jest-editor-support to jest 27.x this week, and noticed this issue that seems to be related to #9898.

We have no problem running jest for these packages but encountered all kinds of dynamic import/require issues when trying to bundle them for the extension via webpack. It seems in 27.x, jest expects many dependencies will be imported “externally”, thus the “requireOutside” directive. But in the tool-chain scenario, these dependencies need to be treated as “internal”, resolved and bundled during packaging.

Maybe the code can support both internal and external import (with optional import?) or maybe there is some trick we need to do in our webpack.config.js? I tried a few of them (webpack-ignore-dynamic-require, noParse…) and none worked: either webpack package error or runtime “module not found” error. Also, the dynamic import has increased the bundle size quite significantly because webpack can not resolve the exact dependency.

It is not ideal for each tool-chain library to hack around this, but if that is what it takes right now, would appreciate some guidance on how to bundle these libraries correctly…

Environment

System:
    OS: macOS 11.6
    CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
  Binaries:
    Node: 14.17.6 - ~/.nvm/versions/node/v14.17.6/bin/node
    Yarn: 1.22.5 - /usr/local/bin/yarn
    npm: 6.14.15 - ~/.nvm/versions/node/v14.17.6/bin/npm
  npmPackages:
    jest: ^27.2.0 => 27.2.1

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 15 (12 by maintainers)

Most upvoted comments

Ok, so 1) is a separate problem with https://github.com/nicolo-ribaudo/babel-preset-current-node-syntax because it require.resolves with a dynamic template string and webpack has no idea what the dynamic part could be so it considers too many things for it. /cc @nicolo-ribaudo 2) I just checked using a simple project that does require(require.resolve('chalk')) compiled with webpack targeting 'node', and even this fails to run because webpack doesn’t handle the require.resolve at all, no matter if it’s a special one like we use or a standard one. But using require.resolve in packages meant for Node (like jest-snapshot) is completely legit and not unusual, so if bundling this with webpack fails that’s not really on us, either webpack configuration needs to be adjusted to handle this correctly, or webpack needs to do a better job on this natively (I do not know if there is a reason they haven’t implemented this by default).

jeysal on Sep 28, 2021