You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
dreamorosi opened this issue
May 21, 2025
· 0 comments
· May be fixed by #3959
Assignees
Labels
confirmedThe scope is clear, ready for implementationinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
Despite us shipping both CJS and ESM builds to npmjs, our codebase runs TypeScript primarily as commonjs. This is a relic of the v1 codebase that was never updated.
Some packages in the ecosystem - ironically including us - are starting to leverage sub-path exports to provide granular exports to different parts of the package. This is what Zod is doing to ship v3 alongside v4, respectively under zod/v3 and zod/v4.
While we haven't decided yet when we're going to upgrade to Zod v4, we will probably have to update the imports in our codebase from using zod to use zod/v3 sometime soon. Currently Zod aliases zod to v3, but once that changes things might start breaking. Updating the imports also helps customers immediately understand which version we support.
In order for us to do this, we need to change the module resolution config in the tsconfig.json file, and the option we want to use requires ESM (others are compatible with CJS but since we're switching we might as well switch to the best config).
Because of this, we should update our tsconfig.json files accordingly.
Why is this needed?
So that we can facilitate the migration to newer module schemes (i.e. #3951), and in the future potentially run our unit tests without having a build step.
Which area does this relate to?
No response
Solution
Switch the tsconfig.json (currently CJS) and tsconfig.esm.json to tsconfig.cjs.json and tsconfig.json (to become ESM).
dreamorosi
added
internal
PRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
confirmed
The scope is clear, ready for implementation
labels
May 21, 2025
confirmedThe scope is clear, ready for implementationinternalPRs that introduce changes in governance, tech debt and chores (linting setup, baseline, etc.)
Summary
Despite us shipping both CJS and ESM builds to npmjs, our codebase runs TypeScript primarily as
commonjs
. This is a relic of the v1 codebase that was never updated.Some packages in the ecosystem - ironically including us - are starting to leverage sub-path exports to provide granular exports to different parts of the package. This is what Zod is doing to ship v3 alongside v4, respectively under
zod/v3
andzod/v4
.While we haven't decided yet when we're going to upgrade to Zod v4, we will probably have to update the imports in our codebase from using
zod
to usezod/v3
sometime soon. Currently Zod aliaseszod
to v3, but once that changes things might start breaking. Updating the imports also helps customers immediately understand which version we support.In order for us to do this, we need to change the module resolution config in the
tsconfig.json
file, and the option we want to use requires ESM (others are compatible with CJS but since we're switching we might as well switch to the best config).Because of this, we should update our
tsconfig.json
files accordingly.Why is this needed?
So that we can facilitate the migration to newer module schemes (i.e. #3951), and in the future potentially run our unit tests without having a build step.
Which area does this relate to?
No response
Solution
Switch the
tsconfig.json
(currently CJS) andtsconfig.esm.json
totsconfig.cjs.json
andtsconfig.json
(to become ESM).Acknowledgment
Future readers
Please react with 👍 and your use case to help us understand customer demand.
The text was updated successfully, but these errors were encountered: