Closed JoseLion closed 2 years ago
I'm getting this error with nextjs as well preventing me from using datetime2
There's nothing fundamentally different in the datetime2 package as far as TS configuration and the emitted CommonJS / ES module .js files (compared to core, datetime, etc.).
I suspect the problem has to do with configuration of ts-node, mocha, or something else in your build stack.
There's nothing fundamentally different in the datetime2 package as far as TS configuration and the emitted CommonJS / ES module .js files (compared to core, datetime, etc.).
I suspect the problem has to do with configuration of ts-node, mocha, or something else in your build stack.
issue is lodash-es is published as an esm. It is used by the cjs output by datetime2 and this causes error as some bundler does not transform anything in node_modules
https://github.com/palantir/blueprint/blob/develop/packages/datetime2/src/common/getTimezone.ts#L17
and inside lib/cjs/common/getTimezone.js
exports.getCurrentTimezone = void 0; var lodash_es_1 = require("lodash-es");
requiring lodash-es , which inside lodash-es uses import (esm) Error: require() of ES Module /home/wmira/dev/x123/node_modules/lodash-es/lodash.js from /home/wmira/dev/x123/node_modules/@blueprintjs/datetime2/lib/cjs/common/getTimezone.js not supported. Instead change the require of lodash.js in /home/wmira/dev/x123/node_modules/@blueprintjs/datetime2/lib/cjs/common/getTimezone.js to a dynamic import() which is available in all CommonJS modules.
@adidahiya if you search:
https://github.com/palantir/blueprint/search?q=lodash-es
DateTime2 is the one that is using lodash-es? maybe it should use the normal cjs lodash package instead?
possible we change the import to:
import memoize from 'lodash/memoize'
and
import isEmpty from 'lodash/isEmpty'
for those having issue under nextjs, try this fix:
/** we import the esm version of the lib */
import { DateInput2 } from "@blueprintjs/datetime2/lib/esm";
use next-transpile-modules on next.config.js to ignore datetime2 and lodash-es
/** next.config.js */
const withTM = require('next-transpile-modules')(['@blueprintjs/datetime2', 'lodash-es']);
const nextConfig = {
reactStrictMode: true,
swcMinify: true,
}
module.exports = withTM(nextConfig)
and above should work with DateTime2
Ah, ok, I see the problem now. I guess we have a couple options here:
@blueprintjs/datetime2
, only export the /lib/esm
folder and omit /lib/cjs
lodash
like you suggested, e.g. import isEmpty from "lodash/isEmpty"
(1) is something I'd like to do eventually, but I don't think that's a breaking change I want to commit to for Blueprint v5, so I think we're stuck with option (2) for now. Maybe in Blueprint v6 we will drop CommonJS modules and only export ES modules as the package public APIs.
Doing some research for this, it looks like many other library authors hit this problem with optimizing lodash imports as well. There are a few solutions out there to simultaneously support CJS and ESM, but they don't look very attractive to me at the moment. I think the cleanest approach is to drop CJS support in a future major version as I suggested above.
See:
Environment
Code Sandbox
N/A
Steps to reproduce
@blueprintjs/datetime2
package component.ts
test for the componentts-node
andmocha
to run the tests without the need to compile the.ts
file firstActual behavior
The following error is thrown before the tests can start running:
Expected behavior
Tests should run with no problem with
ts-node
Possible solution
Based on the stack trace of the error, it looks like the problem is related to the ES module loader. I couldn't find any different configuration in the
@blueprintjs/datetime2
package compared to@blueprintjs/datetime
except for one extra dependency indatetime2
: "lodash-es": "^4.17.15"On that same note, if I try to set up mocha to use the experimental ts-node/esm loader I get the following error: