@swc-node/register/register giving error 'is not defined by "exports"'

[somewhatabstract]

Version

20.19.0

Platform

Darwin <MyMachineName>.local 22.6.0 Darwin Kernel Version 22.6.0: Thu Sep  5 20:47:01 PDT 2024; root:xnu-8796.141.3.708.1~1/RELEASE_ARM64_T6000 arm64

Subsystem

No response

What steps will reproduce the bug?

Write a little executable JS script for running non-ESM TypeScript files using the @swc-node/register/register import, and run it.

How often does it reproduce? Is there a required condition?

Every time.

What is the expected behavior? Why is that the expected behavior?

With Node 20.18.x or using the --no-experimental-require-module with v20.19.0, this works.

The script should just run as it did before.With Node 20.18.x or using the --no-experimental-require-module with v20.19.0, this works.

What do you see instead?

With 20.19.0, it gives the error: Error: Package subpath './register' is not defined by "exports" error.

Additional information

It appears that the @swc-core/register package defines the register export as a require. I suspect that this is causing node to just ignore it when imported.

[kevinb-khan]

For additional context, the package.json for @swc-core/register contains the following "exports" dictionary:

  "exports": {
    ".": {
      "node": "./index.js"
    },
    "./read-default-tsconfig": {
      "node": "./lib/read-default-tsconfig.js"
    },
    "./register": {
      "require": "./lib/register.js"
    },
    "./esm": {
      "import": "./esm/esm.mjs"
    },
    "./esm-register": {
      "import": "./esm/esm-register.mjs"
    }
  }

[ljharb]

You didn’t provide the code for the script; do you mean that using import to bring it in fails?

[somewhatabstract]

You didn’t provide the code for the script; do you mean that using import to bring it in fails?

Yes, the use of the import gives the error. I can try to create a repo that repros, but I wanted to report the main issue just to get it documented.

[ljharb]

cc @joyeecheung for a possible require(esm) bug

[joyeecheung]

Based on the rough description it sounds like previously the code you have containing import may get magically transpiled by something when it can't be simply require-ed, and then your import are transpiled into require so can hit the require exports condition; but now that it can be simply require-ed, it gets loaded directly as ESM by that thing, and the import you have is no longer magically transpiled to require instead, and can no longer hit the require exports condition.

Without a repro it's hard to say what is doing that, but my guess is you'll either need to import from "@swc-node/register/esm-register" instead of import from "@swc-node/register/register" (the latter would not have worked in vanilla Node.js, and it was probably only working due to some transpilation that is patched into Node.js's module loading), or get whatever transpiling your code force the transpilation (perhaps with some config), or get @swc-core/register to add "./lib/register.js" as "module-sync" so that it can also be imported (that might not be actually working since the "./lib/register.js" implements customization by monkey patching the CJS loader via priates so won't work on actual ESM).

[somewhatabstract]

Thanks for the response @joyeecheung. I will try to get a small repro together so you can confirm your suspicions.

[somewhatabstract]

What you describe makes sense to me. I have dug in a little deeper. My current understanding is that the code that loads this is, itself, being transpiled by @swc-node/register to be a piscina worker. So, what you say definitely rings true.

I tried using @swc-node/register/esm-register but it doesn't work (possibly because of the parent @swc-node/register/register use. I also tried require, but that also had issues (again, likely for the same reason of the parent transpilation).

Hopefully, when I get the repro together, it will all become clear (or I'll have fixed it).

[somewhatabstract]

@joyeecheung So, if we use @swc-node/register/esm-register instead; this is the output that we get.

node:internal/event_target:1105
  process.nextTick(() => { throw err; });
                           ^
Error: Unexpected status of a module that is imported again after being required. Status = 0
This is caused by either a bug in Node.js or incorrect usage of Node.js internals.
Please open an issue with this stack trace at https://github.com/nodejs/node/issues

    at Function.fail (node:internal/assert:20:9)
    at ModuleJobSync.run (node:internal/modules/esm/module_job:370:12)
    at ModuleLoader.import (node:internal/modules/esm/loader:540:40)
    at getHandler (/Users/jeffyates/khan/webapp/services/static/node_modules/.pnpm/piscina@4.8.0/node_modules/piscina/src/worker.ts:58:15)
    at /Users/jeffyates/khan/webapp/services/static/node_modules/.pnpm/piscina@4.8.0/node_modules/piscina/src/worker.ts:93:7
Emitted 'error' event on Piscina instance at:
    at EventEmitterReferencingAsyncResource.runInAsyncScope (node:async_hooks:206:9)
    at Piscina.emit (node:events:170:18)
    at ThreadPool._onError (/Users/jeffyates/khan/webapp/services/static/node_modules/.pnpm/piscina@4.8.0/node_modules/piscina/src/index.ts:344:28)
    at Worker.<anonymous> (/Users/jeffyates/khan/webapp/services/static/node_modules/.pnpm/piscina@4.8.0/node_modules/piscina/src/index.ts:292:12)
    at Worker.emit (node:events:524:28)
    at Worker.[kOnErrorMessage] (node:internal/worker:333:10)
    at Worker.[kOnMessage] (node:internal/worker:344:37)
    at MessagePort.<anonymous> (node:internal/worker:233:57)
    at MessagePort.[nodejs.internal.kHybridDispatch] (node:internal/event_target:831:20)
    at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28) {
  code: 'ERR_INTERNAL_ASSERTION'

[somewhatabstract]

OK, I made my repro and found the issue that fixes things. I couldn't quite repro the full issue as my repro is broken in both 20.18 and 20.19, whereas in our larger failing setup, it works in 20.18. I haven't worked out why, but transpilation somewhere is likely the reason.

Anyway, in my repro, there are two executables; run-works.ts and run-broken.ts.

The difference? The file that imports @swc-node/register/register has the extension .mjs in the broken one, and .js in the working one. 🤦🏻

So, in conclusion, I don't think this is a bug on your side. I'll leave it to y'all to close out or whatever your process is.

Here's my little repro repo, in case you find it helpful.

https://github.com/somewhatabstract/repro-node-57536

[joyeecheung]

Thanks for the update, closing