Not compatible with TypeScript

[theKashey]

Long story short - publishing d.ts should fix an issue, with a breaking change (probably it worth to complement the update with a codemod)

- import * as cx from 'classnames';
+ import cx from 'classnames';

---

The current version of classnames is not exposing default in a ESM format, as well as d.ts has no mention of it. As a result import * as cx from 'classnames', is a correct way to load this module from a TypeScript perspective.
However, if the result code would be compiled down using Babel, and Babel can compile TypeScript this would lead to the runtime exception - cx is not an object

The reason is _interopRequireWildcard helper, which would convert classnames to the {default: classnames}, which is yet - not a function.

While webpack is managing "harmony imports" by it's own, and managing in a correct (from TypeScript point of view) way - import * == module.exports, babel is more ESM modules compatible, and wildcard import is working differently in that case.

Proposal:

• update classnames to contain _esModule property to make it ESM compatible.
• ideally - expose ESM bundle
• update d.ts to contain only default export (breaking change), to resolve this issue.

See babel/babel#10574 (comment) for details.

[nicolo-ribaudo]

The d.ts file already contains export default classNames:

classnames/index.d.ts

Line 15 in 5d971e4

export default classNames

Which error does typescript report if you do import classnames from "classnames"?

[theKashey]

It does not throw an error in this case. As well it does not throw an error for import * as classnames and that was how historically classnames were supposed to be imported, as long as local d.ts was updated just a year ago.

As a result - the main problem here is @types/classnames, which shall be removed, as long as they are containing the unsafe definitions, and historically are included in many projects.

However, _esModule prop still has to be defined.

However, the current package.json is incorrect, and does not list index.d.ts as well as bind.d.ts in files, so they would not be bundled into npm package.
Even more - the published version is a bit older, and does not contain any types.

So, long story short - no, this ain't going to work.

[doxiaodong]

the index.d.ts was not be published

[mitsuruog]

Seems index.d.ts is not published. please add the bellow section to your package.json

"files": [
  "index.d.ts"
]

or the workaround is just to use @types/classnames for a while.

[dcousens]

Waiting on #177