Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should we support CommonJS for 3.0? #349

Closed
jonkoops opened this issue Dec 29, 2023 · 5 comments
Closed

Should we support CommonJS for 3.0? #349

jonkoops opened this issue Dec 29, 2023 · 5 comments
Assignees
Labels
Milestone

Comments

@jonkoops
Copy link
Collaborator

See the discussion under #348 for a background on this, we might still want to consider supporting CommonJS next to ESM, but it comes with it's own caveats.

@jonkoops jonkoops added this to the 3.0.0 milestone Dec 29, 2023
@jonkoops jonkoops mentioned this issue Dec 29, 2023
@remcohaszing
Copy link
Contributor

Some considerations:

  • Dual package hazard
  • Publishing both CJS and ESM, also means you need to publish type definitions for both CJS and ESM. Even in case they have the same content, their file extension makes them behave differently.
  • module.exports is not the same as export default. Neither is module.exports.default. Ideally you switch to named exports to minimize exports compatibility issues.

@jonkoops
Copy link
Collaborator Author

Even in case they have the same content, their file extension makes them behave differently.

In all likelihood we'd have to roll bespoke type definitions for both CommonJS and ESM to be actually correct, considering the TypeScript compiler cannot emit types for a different module format.

@jonkoops jonkoops changed the title Should we support CommonJS for v3.0? Should we support CommonJS for 3.0? Dec 29, 2023
@dcousens
Copy link
Collaborator

dcousens commented Dec 29, 2023

Alternatively, we let the dust settle on the 2.x.y branch for a few weeks, and if that remains stable, we then go ESM only for 3.0.0

@jonkoops
Copy link
Collaborator Author

That would have my preference as well, the way I see it we can keep supporting 2.x, so if users need time to migrate they can keep using that version for the foreseeable future.

@jonkoops
Copy link
Collaborator Author

jonkoops commented Jan 8, 2024

I'll consider this as a resolved discussion, we can make 3.0 entirely ESM, as it will simplify the maintenance for us, and reduce the amount of weird edge-case bugs we might not be able to foresee. I can commit to supporting 2.0 with bug fixes and security patches, so users that cannot migrate to directly can continue to use that version.

@jonkoops jonkoops closed this as completed Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants