This fixes a ton of weird bugs we are having, such as __name not defined in our webpack bundle, and made our code run much faster, while still working with ESM modules.

Prevents the following error thrown when projects like ts-node also try to register .mjs.

TypeError: Cannot assign to read only property '.mjs' of object '[object Object]' w

This can happen in dependencies like cosmic-config that use ts-node because they don't know that tsx is already loaded.

In my Jest config I have import '@esbuild-kit/cjs-loader'; so that the config can load node modules that use ESM.

However, because we don't have a way to unregister the loader, it continues to be used through all of the tests, slowing down Jest and double-compiling those that we want transformed.

Ideally, it would be something like:

import { unregisterLoader } from '@esbuild-kit/cjs-loader';
import { } from 'esm module 1';
import { } from 'esm module 2';

unregisterLoader();

// rest of Jest config.

I've ran into a problem using tsx and managed to isolate the problem as an issue with @esbuild-kit/cjs-loader and cssom. When using the loader, the cssom parser fails, but not when using e.g. esbuild-register or no loader. I've reproduced the problem and included the necessary files in this issue. However, I'm not knowledgeable enough to know where to look next, so it would be great if I can get some help.

I noticed that tsx correctly resolves to .ts files when the import ends with .js. But it does not work if the file is behind a TypeScript path alias.

This demonstrates the problem: https://stackblitz.com/edit/node-uvmbub?file=index.ts

The proposed change works well in my project. If you agree, I can also make a corresponding PR for esm-loader

Summary

This PR adds support for ESBK_TSCONFIG_NAME=tsconfig.custom.json and passes it down to get-tsconfig.

(This will be used for the upcoming tsx --tsconfig arg)

No behavioral change.

Minor refactor to remove explicitly registering loaders for .cjs, .cts, and .mts because Node.js' CJS loader actually just fallsback unrecognized extensions to the .js loader.

That said, transformations are still applied.

Problem

Dynamically importing an ESM .js file resulting in getting wrapped in {"default": ... }.

Importing the following would look like this:

export default 1234

{"default":{"default":1234}}

Changes

• New core-utils transforms dynamic imports to interop with transformed modules. Although this is a feature, it's also a breaking change.

Bug description

I have a project that runs a custom Karma server. It is custom because I want to use ESM for Karma while it supports only CJS by default. However, if I try to run it with tsx (command is tsx karma.config.ts), the server fails with the following error:

07 11 2022 16:25:58.760:ERROR [karma-server]: Server start failed on port 9876: Error: No provider for "proxies"! (Resolving: webServer -> proxies)
<root>\node_modules\di\lib\injector.js:22
    return new Error(stack ? msg + ' (Resolving: ' + stack + ')' : msg);
           ^

Error: No provider for "proxies"! (Resolving: webServer -> proxies)
    at error (<root>\node_modules\di\lib\injector.js:22:12)
    at Object.get (<root>\node_modules\di\lib\injector.js:9:13)
    at get (<root>\node_modules\di\lib\injector.js:54:19)
    at <anonymous> (<root>\node_modules\di\lib\injector.js:71:14)
    at Array.map (<anonymous>)
    at Object.invoke (<root>\node_modules\di\lib\injector.js:70:31)
    at createWebServer (<root>\node_modules\karma\lib\web-server.js:65:44)
    at Array.invoke (<root>\node_modules\di\lib\injector.js:75:15)
    at Object.get (<root>\node_modules\di\lib\injector.js:48:41)
    at Server._close (<root>\node_modules\karma\lib\server.js:438:38)

However, it works correctly if I use node --loader @esbuild-kit/esm-loader karma.config.ts instead, it works as expected.

Also, I noticed that if I use two loaders (for ESM and CJS) at the same time (command node --loader @esbuild-kit/esm-loader -r @esbuild-kit/cjs-loader karma.config.ts), it also fails with the same error.

Reproduction

1. Clone this repo.
2. npm install
3. npm run test

Environment

  System:
    OS: Windows 10 10.0.22000
    CPU: (12) x64 12th Gen Intel(R) Core(TM) i7-1255U
    Memory: 22.32 GB / 47.71 GB
  Binaries:
    Node: 19.0.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD
  npmPackages:
    tsx: ^3.11.0 => 3.11.0

Can you contribute a fix?

• [ ] I’m interested in opening a pull request for this issue.