`dayjs` does not actually support Node.js ESM

[CyanSalt]

Node.js has implemented native support for ESM in the real world, and the community is increasingly recommending the use of ESM instead of CommonJS (e.g: https://blog.sindresorhus.com/get-ready-for-esm-aa53530b3f77).

I noticed that dayjs actually publishes the esm directory, which contains the compiled product of the ESM syntax, see #1298. Although the "module" field of package.json was removed in #1314, the contents of esm are actually still available in the <script type="module"> in browsers or in bundling tools such as webpack.

Unfortunately, Node.js requires more than that for ESM. Since this is a CommonJS package, the ESM files it provides must use the .mjs extension to be properly parsed by Node.js.

I can get a few ways to solve this problem, but perhaps none of them are very good:

• The easiest way to make it work is to replace the .js extension with .mjs in build/esm.js, but obviously this will cause breaking changes for scenarios that already use ESM files.
• We can also publish a new node-esm directory for .mjs files for Node.js. But node-esm is not a good name for forward compatibility reasons.
• Further, as described in #1314, continue to push the implementation of the dayjs-esm package, just like lodash-es.
  • If we take this approach, we also no longer need to use the .mjs extension. Just keep using .js.

I'm not sure if you have plans for this in terms of Node.js ESM, but I think that this is the way to go.

[katerlouis]

Any news here?

[benmccann]

2.0 supports ESM

[steffanhalv]

2.0 supports ESM

import dayjs from 'https://cdn.jsdelivr.net/npm/dayjs@2.0.0-alpha.2/dist/index.mjs'
console.log(dayjs()) // It works 👍🏼

[michaelhays]

Looks like the 2.0 alpha may be abandoned -- no new commits or releases in 6 months.

Is there a plan to re-open work on 2.0, or to bring ESM support to 1.0?

[neilsoult]

Looks like the 2.0 alpha may be abandoned -- no new commits or releases in 6 months.

Is there a plan to re-open work on 2.0, or to bring ESM support to 1.0?

BUMP

[MonsterDeveloper]

Any ETA on ESM arrival on NPM?

[DaniilIsupov]

I'm also waiting for Node.js ESM support

[Lauro235]

Would be great to get ESM support!

[andyg3]

Another vote here for ESM support.

[n3ih7]

Come on! Where is ESM support?

[0x80]

Damn I just wasted hours on this 🤦‍♂️ When converting a large codebase to a monorepo, I kept getting errors like this at runtime:

Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/Users/me/myproject/ services/fns/node_modules/dayjs/plugin/advancedFormat' imported from /Users/me/myproject/services/fns/dist/index.js Did you mean to import dayjs@1.11.10/node_modules/dayjs/plugin/advancedFormat.js?

I couldn't figure it out because my bundled shared packages output looked correct, but I assumed it must be a mistake in some configuration. I tried everything I could think of before landing here.

I did not imagine a popular library like this would not have support for ESM yet in 2024.

I'll give the alpha 2.0 a try. Also found this issue describing that it should work by adding the .js import. It is unexpected, because extension prefixes are only required on ESM imports from relative paths, and never from an external library, but that must be a side effect of the funky not-really-esm exports.

[0x80]

The types in 2.0 alpha didn't seem to work for me. For example, TS didn't recognize that .utc() was available after applying the plugin. I ended up sticking .js to the v1 imports and that works for now.

[blackfalcon]

Running SSR build with Svelte/Vite

(node:29857) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
(Use `node --trace-warnings ...` to show where the warning was created)
/Users/dalesande/src/personal/sveltekit-auro/node_modules/dayjs/esm/index.js:1
import * as C from './constant';

Not sure if this is the fix you want, but I simply updated all the JS references to be .mjs and that fixed it. I pushed up a branch of the changes. The tests don't work, but thought this would be easy to see the diff.

https://github.com/iamkun/dayjs/compare/dev...blackfalcon:dayjs:dev

[alex-arriaga]

Another vote here for ESM support.

[michaelhays]

Two years on and nothing on proper ESM support tells me this is a dead end project and I need to migrate my code to another library. ESM is the only way forward, that is written on the wall.

Pretty much, I'm just waiting patiently for https://github.com/tc39/proposal-temporal to hit Stage 4 so I can migrate my Day.js code to that :pray:

[blackfalcon]

Two years on and nothing on proper ESM support tells me this is a dead end project and I need to migrate my code to another library. ESM is the only way forward, that is written on the wall.

The current version covers my use case, time to fork.

[tangxiangmin]

looks bad but work fine 🙅🏻‍♀️

Has there been any progress on this issue?

[manchicken]

@codyfrisch: With all of the folks forcing us to ESM, regardless of technical benefit, this seems like it's going to continue to be a problem.

[manchicken]

From @codyfrisch: You mean developers choosing to use an official ECMAScript standard that is intended to be universal between backend and frontend, supports async module loading, and tree-shaking is "forcing" you to not live in the past? Got it.

You're coming in hot, friend. I'm talking about the trend of module maintainers changing away from supporting commonjs to ESM-only, and suggesting that it's "where the ecosystem is going" while only considering the preferences TypeScript enthusiasts and React developers.

There are a number of folks using Node for automation and systems-level scripts, and it seems all of the front-end web enthusiasm is the only thing anybody really cares to consider when making these decisions.

[manchicken]

From @codyfrisch: Okay boomer. J/K. I've never advocated removing CJS entirely. But refusing to support ESM properly is a great way to see your library die. Only reason I keep dayjs around is because it adheres to the non-standard formatting strings moment used. (there is a unicode standard that date-fns follows, and I expect temporal will follow.)

And reality check 97% of my projects are node for automations and system level scripting. All has been ESM for well over a year. I've worked around DayJS by implementing a helper that just replaces Y with y and D with d in formatting strings and use date-fns. (Format input is user supplied and I need to support their legacy expectation.)

So maybe it's a hot take, but nothing is holding you back except yourself.

I'm sorry friend, but you being fine with something is not an adequate substitute for the broader community being considered in decision-making.

Folks making decisions to break away from one approach or another do have an impact on a great number of people, and as a maintainer of several projects myself I'm always careful to be cognizant of that fact. I am genuinely glad to hear that this time it wasn't you. As you continue your own work, I sincerely hope that you continue your streak of good luck.

How we treat each other does matter.

[manchicken]

looks bad but work fine 🙅🏻‍♀️

Has there been any progress on this issue?

I confirm that this works.