Support for ESM in TypeScript projects

[fvictorio]

Please comment and/or upvote this issue if you need support for ESM in TypeScript projects. If possible, tell us more about your use case and why you need this and cannot just transpile to cjs.

UPDATE: We have an experimental version working

See this comment to learn how to use an experimental version of this: #3385 (comment)

[github-actions]

This issue is also being tracked on Linear.

We use Linear to manage our development process, but we keep the conversations on Github.

LINEAR-ID: b31f8c05-52a3-44ca-b22e-10ec21278d4c

[matthewlilley]

@fvictorio we use wagmi/core for some scripts which only supports ESM. Had to convert all tests to .js and extract chunks of scripts into another package for now to deal with this.

sushi-labs/sushiswap@ccd68f9

[DenisGorbachev]

I'm using https://github.com/sindresorhus/execa, which is ESM-only.

[anteqkois]

I can't run task when use new TypeScript:

"module": "NodeNext",
"moduleResolution": "NodeNext",

Obviously when i delete "type": "module" from package.json it's start work, but i must use this setting.

Error from terimnal:

[talentlessguy]

Suggestion for TS ESM implementation:

ts-node has a ts-node/esm loader hook. Also mts extension could be used but I'm not sure if that's needed.

[paulmillr]

Copying @alcuadrado comments from monorepo:

Nop, unfortunately Hardhat's core depends on CJS pretty heavily.

The reason for that is that our plugin system is dependent on the order of require() that users make to plugins. In ESM the order of imports is not guaranteed (and does change in practice).

What about await import? You can do this one after another.

We need to rework our plugin system for it to fully support ESM.

I'm starting to think that maybe we should move to esm-only when it's properly supported by ts-node or some similar project. But note that even after that, the migration would be a pretty large project, as every plugin will need to be adapted.

If you keep supporting two module systems, ESM modules would be able to import common.js code - which uses old sequential requires and is cool.

[alcuadrado]

What about await import? You can do this one after another.

Oh, that may be a great idea actually! I think now ESM in node.js means/implies that you have top-level-await. This could work! Thanks !

[alex-mccreary]

Upvote; we are using ESM in our TypeScript project because of a dependency requirement.

[pynixwang]

pure esm package is coming.

[thevolcanomanishere]

I am looking to integrate Playwright with Hardhat + Wagmi in order to automate frontend testing that involves connecting to a hardhat node :)

[kostysh]

Upvote; we are using ESM in our TypeScript project

[highskore]

pure esm package is coming.

do u know when? 🧐

[robwilkes]

upvote, many packages are ESM only now, I have to install older versions for compatibility. all my projects and code is ESM now, except for hardhat.

[CJ42]

Upvoting as well. We have constants values defined in a constants.ts / constants.js file in the LUKSO lsp-smart-contracts. These are part of the @lukso/lsp-smart-contracts npm package and are important values to be consumed by projects that use our smart contracts package.

https://github.com/lukso-network/lsp-smart-contracts

In our case, this is problematic as any Hardhat Typescript project that has the @lukso/lsp-smart-contracts as a dependency cannot import these necessary constant values.

The only workaround we found was in this PR by @richtera: lukso-network/lsp-smart-contracts#601.

https://github.com/lukso-network/lsp-smart-contracts/pull/601/files

The file in the folder looks like this:

ES Lint raises a warning, but we are still able to import as shown below.

import { INTERFACE_IDS } from "@lukso/lsp-smart-contracts/dist/constants.cjs.js";

const test = INTERFACE_IDS.LSP0ERC725Account;

[vinerz]

Following this issue. Would help a lot to get rid of some workarounds for ESM/CJS interop.

[damianobarbati]

Is there any news on the topic from the team? Should the user expect the project to be stuck on the old CJS or was any progress made with ESM? Thanks guys for the effort.

[kanej]

Is there any news on the topic from the team? Should the user expect the project to be stuck on the old CJS or was any progress made with ESM? Thanks guys for the effort.

The team is currently focused on the next version of Hardhat, which will support ESM.

[0xVinCal]

It would be great if the next version could be used with bun

[ppciesiolkiewicz]

Just letting you know

---

Needed to use permissionless lib from Pimlico

[lbltavares]

@kanej no news about this? do you know a good alternative to hardhat that we can use to finally have esm?

[kanej]

Hardhat 3 will have support for ESM, it is currently in private Alpha. I am not aware of an ESM supporting alternative currently.

[vinerz]

Amazing news @kanej! Is there a possibility of joining this alpha group?

[0xVinCal]

@kanej , I would be interested to join the private alpha

[rhlsthrm]

I am also interested in joining private alpha.

[olehmisar]

@kanej i want to join private alpha as well. Completely blocked by lack of ESM support with typescript

[olehmisar]

i managed to import esm like this:

const { tsImport } = require("tsx/esm/api")
const mod = await tsImport("./my-esm-module", __filename); 

https://tsx.is/dev-api/ts-import#commonjs

[CJ42]

Seems that Hyperlane has an interesting approach to enable ESM with Typescript in their monorepo.

https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/170a0fc73922297b1163316825bd98ff352fe57f/solidity/package.json#L73

Snippet of their package.json

"scripts": {
    "build": "yarn version:update && yarn hardhat-esm compile && tsc && ./exportBuildArtifact.sh",
    "hardhat-esm": "NODE_OPTIONS='--experimental-loader ts-node/esm/transpile-only --no-warnings=ExperimentalWarning' hardhat --config hardhat.config.cts",
    // ...
  },

[canastro]

Is there any way to get access to the alpha testing of hardhat? I've tried following the steps in this comment but I always face a few different problems, eg. problems with @nomicfoundation/hardhat-chai-matchers

[kanej]

Is there any way to get access to the alpha testing of hardhat? I've tried following the steps in this comment but I always face a few different problems, eg. problems with @nomicfoundation/hardhat-chai-matchers

Hey @canastro, thanks for the interest. The alpha is still very rough and lacks many basic features; it is not usable for general development currently, instead being more a test bed for new capabilities.

[canastro]

I found a workaround that might be specific to my use case:

I have an npm package containing my smart contracts, which I need to import into other packages within my monorepo. Since the package needs to be ESM, my main goal is to export only the Typechain factories.

To address this, I implemented the following steps:

• Based on this comment, I created a hardhat-esm command and replaced all scripts.
• Following this comment:
  • Updated my tsconfig.
  • Modified imports to use hardhat
• Renamed all my test files to .cts extension - this was the piece I was missing

I avoided creating a Hardhat task to generate a package.json in the typechains folder, as doing so would conflict with my goal of exporting the package for use in an ESM context.