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
Fix TypeScript types when using require #276
Conversation
The package uses commonjs, but it’s typed as if it contains faux ESM. This was problematic for people using `require` or the new `node16` module resolution.
Please @JedWatson could you help merge/publish this? This is blocking cases where TypeScript "nodenext" resolution is being used. See this issue for details: microsoft/TypeScript#49189 |
Hi, FYI this is a breaking change for TypeScript consumers which is unexpected in a patch version of the classnames package. Before, we could I understand that this change was made to support a newer TS resolution option, but changes to typings like this should be done carefully to avoid breaking existing consumers. May I ask why you are using |
I see how this affects you and why you consider this breaking. However, I believe this was a bug fix. Any change of behaviour can break code, including bug fixes. You were previously relying on this bug. According to the readme, correct usage of this package is: // CJS
const classNames = require('classnames') // ESM
import classNames from 'classnames' However, before this PR, according to the TypeScript type definitions, correct usage was: // CJS
const classNamesExports = require('classnames')
const classNames = classNamesModule.default // ESM
import classNamesExports from 'classnames'
const classNames = classNamesModule.default The latter technically works too, because The latter didn’t work because it was typed correctly. It worked by accident. The situation you are describing is usage of this package inside a module bundler that allows you to import
The JavaScript ecosystem is slowly moving towards ESM. In order to be able to use newer packages or updates, one has to keep up.
This isn’t a matter of opinion, but of statistics that aren’t presented. I’m inclined to believe this is correct though. What matters is correctness though, not usage statistics.
This didn’t break usage. It highlights a problem in those consumers’ configuration. You would’ve run into the same problem eventually if you added another properly typed dependency. For more information, see https://github.com/DefinitelyTyped/DefinitelyTyped#a-package-uses-export--but-i-prefer-to-use-default-imports-can-i-change-export--to-export-default |
I stand by my previous comment, but I learnt that it is possible to also support the |
The package uses commonjs, but it’s typed as if it contains faux ESM. This was problematic for people using
require
or the newnode16
module resolution.