Error [ERR_REQUIRE_ESM]: require() of ES Module

[viniciusteixeiradias]

Version 1.13.3: Works fine.
Version 2.0.0: Din't work.

I'm using TRPC in my application (Electron + Vite + Vue + Typescript), according to the TRPC documentation I need to install superjson to transport data of types: Date/Map/Set. However, after installing the "superjson": "^2.0.0" lib, I am getting this error when running the application.

App threw an error during load
Error [ERR_REQUIRE_ESM]: require() of ES Module ~/node_modules/superjson/dist/index.js from ~/dist-electron/main/index.js not supported.
Instead change the require of ~/node_modules/superjson/dist/index.js in ~/dist-electron/main/index.js to a dynamic import() which is available in all CommonJS modules.
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at Object.<anonymous> (~/dist-electron/main/index.js:11:19)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at loadApplicationPackage (~/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:121:16)
    at Object.<anonymous> (~/node_modules/electron/dist/Electron.app/Contents/Resources/default_app.asar/main.js:233:9)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at node:electron/js2c/browser_init:2:115657
    at node:electron/js2c/browser_init:2:115860
    at node:electron/js2c/browser_init:2:115864
    at f._load (node:electron/js2c/asar_bundle:2:13330)

tsconfig.json:

{
  "compilerOptions": {
    "target": "ESNext",
    "useDefineForClassFields": true,
    "module": "ESNext",
    "moduleResolution": "Node",
    "strict": true,
    "jsx": "preserve",
    "resolveJsonModule": true,
    "isolatedModules": true,
    "esModuleInterop": true,
    "lib": ["ESNext", "DOM"],
    "skipLibCheck": true,
    "noEmit": true,
    "types": ["vitest/globals"],
    "noUnusedLocals": true,
    "noUnusedParameters": true,
    "paths": {
      "@/*": ["./src/*"],
      "@electron/*": ["./electron/*"]
    }
  },
  "include": [
    "src", 
    "src/**/*.vue"
  ],
  "references": [
    { "path": "./tsconfig.node.json" }
  ]
}

Uso:

// trpc.ts
import { initTRPC } from '@trpc/server';
import SuperJSON from 'superjson';

const t = initTRPC.create({
  transformer: SuperJSON
}); 

export { prisma } from '../prisma';
export const router = t.router;
export const publicProcedure = t.procedure;

// client.ts
import { ipcRenderer } from 'electron';
import { RequestInitEsque } from '@trpc/client/dist/internals/types';
import { createTRPCProxyClient, httpBatchLink } from '@trpc/client';
import type { AppRouter } from '@electron/api/routes/routes';
import SuperJSON from 'superjson';

type TRPCClient = ReturnType<typeof createTRPCProxyClient<AppRouter>>;

const fetch = async (url: RequestInfo | URL, init: RequestInit | RequestInitEsque | undefined) => {
  const response = await ipcRenderer.invoke('trpc', {
    url,
    method: init?.method,
    headers: init?.headers,
    body: init?.body
  });
  
  return new Response(response.body, {
    status: response.status,
    headers: response.headers,
  });
}

const useTRPC = () => {
  return createTRPCProxyClient<AppRouter>({
    transformer: SuperJSON,
    links: [
      httpBatchLink({
        url: '/trpc',
        fetch
      }),
    ],
  });
}

export { fetch, useTRPC }
export type { TRPCClient }

[foloinfo]

I faced same error using "next": "13.5.4". I use "node": "18.18.x" and "yarn": "3.6.4", not sure what's causing the problem.
Falling back to 1.13.3 fixed the issue, thanks @viniciusteixeiradias . Maybe I'll wait for some more update before using 2.0.0

[viniciusteixeiradias]

I faced same error using "next": "13.5.4". I use "node": "18.18.x" and "yarn": "3.6.4", not sure what's causing the problem. Falling back to 1.13.3 fixed the issue, thanks @viniciusteixeiradias . Maybe I'll wait for some more update before using 2.0.0

I'm not sure, but I think the bug is related to this PR: #263

[Skn0tt]

Hi! This looks like an issue with how your TSC is configured.

It likely outputs CJS code that contains require instead of import directives. If you look at the ~/dist-electron/main/index.js file that's referenced in your error message, you can double-check if that's what's happening.

I don't directly spot anything in your tsconfig.json that leads to that, but this is where i'd start to debug this!

The whole CJS -> ESM story is a mess, and the fact that TypeScript uses a syntax that looks like ESM doesn't make things easier. Please make sure to post your solution in this issue, i'm pretty sure a lot of others will run into similar issue!

[peterbud]

I think it is related to the fact that there is no target specified int the tsconfig.json in the superjson library. The default is ES3 and it means the emitted JS is very old style.

For Node16 the recommendation is at least target es2021:
https://github.com/tsconfig/bases/blob/main/bases/node16.json

Have you considered specifying target in the compilerOptions?

[Skn0tt]

@peterbud I don't think it's related to SuperJSON's target config - I've doublechecked that it outputs correct ES Modules code.

[peterbud]

Hi @Skn0tt , thanks for looking into this.

There is no syntactical problem with the code which tsc outputs with the current settings (aka without target)/ The problem is that this 'dialect' is very outdated.

Consider the following:
https://github.com/blitz-js/superjson/blob/ba7346c7fd98170306780128d32e7fe38df7bb34/src/transformer.ts#L125-L132

With the current ES3 it is transpiled to:

    simpleTransformation(isSet, 'set', 
    // (sets only exist in es6+)
    // eslint-disable-next-line es5/no-es6-methods
    function (v) { return __spreadArray([], __read(v.values())); }, function (v) { return new Set(v); }),

Where __read is a generated function which uses this at top level

var __read = (this && this.__read) || function (o, n) {
    var m = typeof Symbol === "function" && o[Symbol.iterator];
    ...
}

leading to a warnings like
The 'this' keyword is equivalent to 'undefined' at the top level of an ES module, and has been rewritten
if you use the library

If you compile with target 'es2020' (with typescript 4.2 that's the best you can use), you get a much better transpiled javascript dialect for the same function:

    simpleTransformation(isSet, 'set', 
    // (sets only exist in es6+)
    // eslint-disable-next-line es5/no-es6-methods
    v => [...v.values()], v => new Set(v)),

If superjson is targeting node16 I think es2020 would be a reasonable minimal target as I have linked above.

[peterbud]

One more thing:
You have mentioned that you have followed Axel Rauschmayer guide: https://2ality.com/2021/06/typescript-esm-nodejs.html

That also specifies target es2020 in tsconfig.json:
https://2ality.com/2021/06/typescript-esm-nodejs.html#tsconfig.json

[Skn0tt]

Good points!

[peterbud]

Thanks @Skn0tt - this has fixed the situation: warnings are gone! Thanks!

[titanism]

Can you please release a CJS export?

[Skn0tt]

ESM is the standard format, has been supported by current Node.js versions for years. We need good reasons to add a CJS export again. If you feel your usecase has specific requirements and is important enough for SuperJSON to revisit its bundling, please outline that and open a separate issue.

[titanism]

You're already using TypeScript which isn't a standard, so your bundler could export CJS format pretty easily. Then just update the package.json and then you can support the majority of users who still use CJS (or dislike ESM).

[queicherius]

We need good reasons to add a CJS export again.

• Jest only supporting ESM behind experimental flags (issue, docs)
• New runtimes releasing, where interop between ESM and CJS are main selling points (docs, blog)
• node-fetch making the same move to ESM-only and being met with a lot of backlash (issue)
• The common workarounds (reference) not working well for use-cases like TRPC (because of missing await top level support without ESM in TS and TRPC wanting a sync transformer function)
• CommonJS modules not being deprecated in NodeJS (docs) and being widely used

Exporting multiple variants would be the most constructive for everyone and can happen seamlessly. Here would be an example of how to do that with TypeScript.

[Skn0tt]

I appreciate the effort in making your point @queicherius! My thoughts on the issue are very much the same that Jimmy Warting mentions here: node-fetch/node-fetch#1263 (comment)

In short, I want the transition period between CJS and ESM to be over, and making packages ESM-only is a good way of doing that. For specific issues that arise from this, i'm happy to help finding workarounds in separate issues.