dayjs: [Bug] Typescript Declaration file error

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)?

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

There hasn’t been any updates to v2 (alpha) git branch since 09/2022, so no, there doesn’t seem to be anything done to improve the ESM/TS situation.