Should we support CommonJS for 3.0?

JedWatson / classnames

A simple javascript utility for conditionally joining classNames together

MIT License

17.61k stars 562 forks source link

Should we support CommonJS for 3.0? #349

Closed jonkoops closed 10 months ago

jonkoops commented 11 months ago

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.

remcohaszing commented 11 months ago

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 commented 11 months ago

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.

dcousens commented 11 months ago

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 commented 11 months ago

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 commented 10 months ago

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.