OpenZeppelin / OpenZeppelin/openzeppelin-ui

Track ESM-only migration for published packages

Open
#131 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
TypeScript
Stars
7
Forks
3
Avg merge
20h 20m
Merged PRs (30d)
26

Description

Summary

The build currently emits a tsdown warning recommending ESM over CommonJS for @openzeppelin/ui-dev-cli because the package intentionally publishes dual esm/cjs outputs.

This is not currently breaking the build, but it would be useful to evaluate whether the published packages in this repo can move to ESM-only output and remove legacy CommonJS packaging over time.

Context

During pnpm build, packages/dev-cli logs:

WARN  We recommend using the ESM format instead of CommonJS.

The CLI currently publishes both formats on purpose, and consumer .pnpmfile.cjs support remains a separate concern.

Goal

Audit the published packages in this monorepo and decide whether we should:

  • keep dual esm/cjs output as-is,
  • suppress/accept the warning as expected noise, or
  • migrate some or all published packages to ESM-only output.

Notes

  • Priority: low
  • This should likely be treated as packaging cleanup / modernization work, not as a release blocker.
  • If pursued, the work should include a consumer compatibility check before removing any require exports.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by running pnpm build and inspect the published package configuration, beginning with packages/dev-cli and its dual ESM/CommonJS outputs. Audit the other published packages and check consumer compatibility, including .pnpmfile.cjs; done means documenting whether to retain dual output, suppress the warning, or migrate packages to ESM-only.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
build-system, release
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.