Day.js added module in package.json in v1.8.1+ , in order to support ES Modules.
However, there's some unexpected behavior while using commonJS require with webpack
And there a discussion from webpack here, https://github.com/webpack/webpack/issues/4742
const dayjs = require('dayjs') // works with 1.8.0 -
const dayjs = require('dayjs') // broken with 1.8.1 +
const dayjs = require('dayjs').default // works with 1.8.1 +
Note: add .default is just a temporary workaround, and it's still a bug with webpack we think. Since default is an artifact of ES Modules and should not appear in CJS requires
@iamkun no, this is what was specified in your source code, here.
If you don't want a .default when using common JS, the exports should be written as module.exports = dayJS (which has no ESM equivalent). The reason why it worked before, is that because if you were exporting commonJS, babel was _assuming_ that with require('dayjs') you were meaning require('dayjs').default (it generates some feature detecting code for that), which so far made seemed that require without default was the commonJS equivalent, but it really isn't
@mweststrate Yes, that's why we have two bundles main: /dayjs.min.js is the umd bundle for commonjs, while module: /esm/index.js is for the ESM.
And webpack just load the module: /esm/index.js no matter it is require or import.
That is what one would expect right? Otherwise your lib might end up twice
in the bundle. The problem seems that your minified bundle does _not_ have
a .default export, so effectively you are shipping a different API in
your commonJS version than in your ESM version
Op di 12 feb. 2019 om 16:17 schreef iamkun notifications@github.com:
@mweststrate https://github.com/mweststrate Yes, that's why we have two
bundles main: /dayjs.min.js is the umd bundle for commonjs, while module:
/esm/index.js is for the ESM.And webpack just load the module: /esm/index.js no matter it is require
or import.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/iamkun/dayjs/issues/492#issuecomment-462799165, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhEu-lpXqJFSROf5namTmKIpxs_Leks5vMtr1gaJpZM4a2JU7
.
For ESM the "namespace" object is returned by
require()(and forimport()). There is no spec for this, but there is a spec forimport(). Babel also transpiles ESM this way.
Exposing only the default export would make all other export inaccessible and most packages un-usable from CJS.As a guideline: When packaging CJS and ESM in a package, expose the same API from both of them. You can't use a function assigned to
module.exports.exports default "something" export var named = "other";exports.default = "something"; exports.named = "other"
https://github.com/webpack/webpack/issues/6584
https://github.com/facebook/create-react-app/issues/6321
You cannot, strictly speaking, support the old CJS interface with ESM exports since it would require making your ESM namespace the dayjs function. Why does this library support ESM at all? No tree shaking benefit, since all the functions are tacked into dayjs or manually imported from plugins.
@Tvrqvoise I don't agree. Seems some of the imported utils and constants is tree-shakable.
@mweststrate @githoniel And the main problem here is webpack is using the wrong file. require for commonjs should use main: /dayjs.min.js instead of module: /esm/index
@xxyx there's only one export in the library, everything else is referred to by it. Current DCE techniques can't trim that out. I've been wrong before though, if you have an example of something that you think could be tree-shook, let me know.
@Tvrqvoise Seems we just do module: /dayjs.min.js will fix everything? I do agreed that at this time, there's no need to support ESM, but is't a nice to have feature right?
Although it is not real ESM ...
@iamkun, yes, but you'll still have the .default problem unless you also switch to CJS exports
@Tvrqvoise
In my test, if changed like this, CJS require will be fine.
"main": "dayjs.min.js",
"module": "dayjs.min.js",
@iamkun could you release a new version to resolve this?
@githoniel
In v1.8.6, I changed module back to the umd version. This might could solve this issue, but of course not a good practice.
"main": "dayjs.min.js",
"module": "dayjs.min.js",
However, we could still use the ESM version like this
import dayjs from 'dayjs/esm'
In version 1.8.27, the type declaration file for 'dayjs/esm' is missing.
Most helpful comment
@githoniel
In v1.8.6, I changed
moduleback to theumdversion. This might could solve this issue, but of course not a good practice.However, we could still use the
ESMversion like this