[Bug] Typescript Declaration file error

[Mister-Hope]

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

[iamkun]

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

[Mister-Hope]

What is the problem ? I read through #1281 and did not found what you mean.

You have already deleted module entry, so align esm/index.d.ts with esm/index.js should be the expect behavior.

Please list one of the problems, I am not catching you and I can not think out one.

[Mister-Hope]

users must explicit use dayjs/esm in es module env now if they want.

And they will read dayjs/esm/index.d.ts when using typescript only by doing import dayjs from 'dayjs/esm', so why should typescript decalre a module.exports intead of a export default?

What are the acual problem?

[BePo65]

I have the same problem:
I use import dayjs from 'dayjs/esm'; and get a warning saying:

index.d.ts(3, 1): This module is declared with using 'export =', and can only be used with a default import when using the 'allowSyntheticDefaultImports' flag.

And that is a correct warning, as dayjs/esm/index.d.ts is identical to dayjs/index.d.ts. That means that dayjs/esm/index.d.ts does not reflect the change in dayjs/esm/index.ts line 433 that says:

export default dayjs;

So I agree with @Mister-Hope that dayjs/esm/index.d.ts needs a change in line 3 with the new content being:

export default dayjs;

or perhaps I am missing an important side effect of such a change :-)

[Mister-Hope]

Nope probably @iamkun isn't expert at ts. And since he used module field to trigger a side effect, he thinks all have a side effect 🤔

[BePo65]

BTW I ran into the same problem when trying to import the customParseFormat plugin: in the index.js it says export default (function (o, C, d)...., but the corresponding index.d.ts says export = plugin.

[Mister-Hope]

BTW I ran into the same problem when trying to import the customParseFormat plugin: in the index.js it says export default (function (o, C, d)...., but the corresponding index.d.ts says export = plugin.

Actually all the declaration files in esm needs to be corrected

[BePo65]

One more point: if dayjs/esm should be a 'esm' version of the package (which in my opinion it definitely should), then of course it will need a package.json of itself with a "type": "module" in it.

Otherwise node will look up the tree for the next package.json and will find that of dayjs. And of course here in the "root" path we must not have a "type": "module" or we will break all existing codes (see the lengthy discussion in issue #1281.

My only problem is that if we want to use the default export plus the destructuring imports at the same time we will have to redefine all exports in the .d.ts files (at least I didn't find a better way). I really don't like code duplication, but probably we will have to go this way. I'm still working of a PR to this.

[Mister-Hope]

One more point: if dayjs/esm should be a 'esm' version of the package (which in my opinion it definitely should), then of course it will need a package.json of itself with a "type": "module" in it.

This will have sife effects in some situation.

If a code wants to work both in cjs and esm when just exporting a function, it should use named export intead of default export.

And this is the issue ikun run into.

Now you should import dayjs/esm to avoid problems. And I don't think a new package like dayjs-esm should be published.

Ikun will probably need to change to named exports and raise to v2 to include them in one package.

[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').

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

[BePo65]

I addressed these points in pr #1581

[Mister-Hope]

Any update of this?

[Mister-Hope]

Any update of this?

[naveedahmed1]

any update?

[hakimio]

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.