[Bug] Typescript Declaration file error

Please convert dayjs/esm/index.d.ts to export default dayjs

Declaration file is using export = which is same to exports in cjs, while the actural code is export default which is exports.default in cjs.

This makes error when the env not allow users to open allowSyntheticDefaultImports and esModuleInterop

[BePo65]

Just to understand the problem I created demo projects for all cases:

1. node using const dayjs = require('dayjs') and with just a plain package.json => everything runs as expected
2. node using import dayjs from 'dayjs' and with "type": "module" in the package.json => everything runs as expected
3. typescript using import dayjs from 'dayjs' and with just a plain package.json and with "compilerOptions": {"allowSyntheticDefaultImports": true, "esModuleInterop": true} in the tsconfig.json => everything runs as expected, as in my understanding this boils down to using the library as umd-/commonjs packages

Now IMHO @iamkun made the clever decision to integrate dayjs as esm package in the generated package in form of a subfolder called dayjs/esm.

So in my program (that is using the dayjs package) if and only if I want to use dayjs as an esm module, I would use dayjs/esm instead of dayjs without changing any other code.

If I do this with dayjs/esm just out of the box, I get the effect that node complains about a missing "type": "module" (as the next package.json up the line does not contain such an entry - and should not, as this would kill the usage of import from 'dayjs').

1. Therefore I added a package.json with "type": "module" into the folder dayjs/esm and without "compilerOptions": {"allowSyntheticDefaultImports": true, "esModuleInterop": true} in the tsconfig.json (ok and I fixed the type definition files to match the export default of the *.js files and have named exports too) and now this runs like a charm.

This way we could have both worlds without using 2 packages (dayjs and e.g. dayjs-esm) and without the problems described in issue #1281 (because like you all confirmed, there is no simple way to configure package.json of a library so that it is possible to use this library as umd/commonjs and esm - at least not in an node environment).

Using 2 different packages is something we should avoid, as this makes development of this great package not really easier - I suppose.

And to the question of semantic versioning: is this really a major (i.e. breaking) change? We only change the type definitions and at least I could not get the current type definitions into compiling without error - so does anyone else?

Or does my “great” solution (just joking 😃 miss some side effects that would kill any existing application using dayjs? At the moment all existing solutions should be using the path dayjs, shouldn’t they)?

[iamkun]

this will introduce a new problem, please refer to #1281