Why do I get "failed to resolve regenerator-runtime"?

[oliversalzburg]

I'm trying to use swc for the first time and I'm not getting very far. When I run spack, I get the following output:

(node:11785) UnhandledPromiseRejectionWarning: Error: load_transformed failed

Caused by:
    0: failed to analyze module
    1: failed to resolve regenerator-runtime from /home/oliver/fairmanager/fairmanager/core-web3/packages/core-api/source/main.ts
    2: not found
(Use `node --trace-warnings ...` to show where the warning was created)
(node:11785) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:11785) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

This is a yarn project that uses PnP. I expected that to be the root cause, but some closed tickets suggest that PnP should already be supported.

.swcrc:

{
  "jsc": {
    "parser": {
      "syntax": "typescript",
      "tsx": false,
      "decorators": true,
      "dynamicImport": false
    },
    "transform": {
      "legacyDecorator": true,
      "decoratorMetadata": true
    }
  }
}

spack.config.js:

module.exports = {
  entry: {
    web: __dirname + "/packages/core-api/source/main.ts",
  },
  output: {
    path: __dirname + "/packages/core-api/output/main.js",
  },
};

[kdy1]

You have to install regenerator-runtime.
It can't be a dependency of @swc/core because it's not a kind of always-required stuff.

[oliversalzburg]

I tried that. I added regenerator-runtime as a devDependency to both my monorepo root and to the package that the error complains about. It had no impact on the issue.

[kdy1]

Do you have /home/oliver/fairmanager/fairmanager/core-web3/packages/core-api/node_modules/regenerator-runtime?
(Assuming core-api/package.json exists)

Currently spack checks for directories named node_modules while loading dependencies. It also checks for node_modules in ancestor directories, but I'm not sure about the way yarn pnp works.

[oliversalzburg]

I do not have any node_modules directory, as yarn PnP eliminates those. So that's likely the root cause then.

I believe access to the module would have to be reimplemented using the PnP API, but I'm not very experienced in this aspect. I assumed this was implemented with #1244.

[mischnic]

PnP doesn't generate a node_modules structure, but instead a kind of manifest. Then there's a preload script for node that monkeypatches require, so that require("regenerator-runtime") is handled by Yarn and it looks up the path that this import should resolve to.

When implementing a bundler in JS, you can use that PnP API yourself, for example Parcel does this here: https://github.com/parcel-bundler/parcel/blob/ba57b6501632703d68923b214b0c0f6d47a34b1f/packages/utils/node-resolver-core/src/NodeResolver.js#L261-L268. The returned path is usually something like path/to/lodash.zip/lib/some.js, so you also rely on Yarn patching Node's fs so that ZIP files can be read transparently.

An alternative to the first part (the PnP API) would be reimplementing the logic in Rust by reading a JSON file that essentially describes how Yarn resolved the dependencies: https://yarnpkg.com/configuration/yarnrc/#pnpEnableInlining

[kdy1]

I filed an issue for this