superjson: Error [ERR_REQUIRE_ESM]: require() of ES Module

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 }

About this issue

Original URL
State: open
Created 8 months ago
Reactions: 17
Comments: 20 (5 by maintainers)

Most upvoted comments

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.

queicherius on Jan 9, 2024

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!

Skn0tt on Oct 20, 2023

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

foloinfo on Oct 20, 2023

Would really appreciate a cjs export, its currently not possible for me to use a esm node server

JClackett on Mar 15, 2024

Can you please release a CJS export?

titanism on Dec 20, 2023

I +1 others’ comments on the pain and difficulty here.

But if helpful to others, here’s how I got a superjson import working in my CommonJS codebase for use with tRPC, using @joepie91’s fix-esm module (in a TypeScript + ESLint codebase):

// HACK: The `superjson` library is ESM-only (does not support CJS), while our codebase is CJS.
// This is a workaround to still get to use the latest version of the library from our codebase.
// https://github.com/blitz-js/superjson/issues/268
// https://www.npmjs.com/package/fix-esm
// eslint-disable-next-line @typescript-eslint/no-var-requires, @typescript-eslint/no-unsafe-assignment
const fixESM = require("fix-esm");
// @ts-expect-error This is a type-only import, so won't get transformed to `require()`.
import type SuperJSON from "superjson";
// eslint-disable-next-line @typescript-eslint/no-unsafe-member-access, @typescript-eslint/no-unsafe-call, @typescript-eslint/no-unsafe-assignment
const SuperJSON: SuperJSON = fixESM.require("superjson");

aseemk on Mar 11, 2024

I have the same problem, I’m unable to use this library. I have a typescript project with Express and trpc and I wanted to use this lib (as suggested from trpc). But after wasting hours, I wasn’t able to fix this, the whole argument of commonJS and ESM for me is always cryptic and it’s not something that I would like to dig in. This is my current config:

{
  "extends": "@tsconfig/node16/tsconfig.json",
  "version": "4.4.2",
  "compilerOptions": {
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "outDir": "./lib",
    "strictPropertyInitialization": false,
    "target": "ESNext",
    "module": "nodenext",
    "moduleResolution": "nodenext"
  },
  "include": ["**/*.ts"],
  "exclude": ["lib", "src/**/*.spec.ts", "node_modules"],
  "ts-node": {
    "files": true
  }
}

I’ve tried everything that make sense to me (esModuleInterop true) changing target/module/moduleResolution, but with no results. The solution for me at this point is simple I won’t use this library

perusopersonale on Mar 4, 2024

I appreciate the effort in making your point @queicherius! My thoughts on the issue are very much the same that Jimmy Warting mentions here: https://github.com/node-fetch/node-fetch/issues/1263#issuecomment-1025241402

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.

Skn0tt on Jan 10, 2024

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

peterbud on Nov 9, 2023

i was toying around with a super basic express/trpc/superjson setup, and for HOURS i could not figure out why none of it was working. I tried changing my config in 1000 different ways, and none of it worked, except for

@aseemk 's answer!!! just, than you, so much !!!

AndreiCravtov on Mar 27, 2024

Same, we are forced to use 1.13.3 for now.

oskarhertzman on Mar 15, 2024