v0.81.0 can lead to import issues #2310
Comments
plouc
changed the title
|
It's a bit bizarre, but maybe it's possible to change the import for d3-scale/color to the victory-vendor package that transpiles the d3 dependencies to CJS if necessary? |
|
Nivo |
|
Still on 0.80.0 because of this. |
|
I'm a little confused -- even after updating to 0.81.0, Am I needing to pin all the Thanks! |
|
It seems like some other d3 packages are installing a different version, but you shouldn't pin all d3 packages to the latest version manually (or at your own risk 😅), there might be some incompatibilities with the current codebase. Also the nivo versions I see in your report are a bit weird, all versions should be aligned, and |
You know what is strange? My I can share the rest privately if it helps, but really my stuff is mostly up to date, and my |
|
Also hitting this issue. The temporary fix from the next.js documentation relating to esmExternals did not resolve this issue for us. Attempting to update to nivo*:0.83.0 using next:13.3.1. |
|
If you're using Next.js, you may be able to resolve this by using From import { ResponsiveLine } from "@nivo/line";to import dynamic from "next/dynamic";
const ResponsiveLine = dynamic(() => import("@nivo/line").then(m => m.ResponsiveLine), { ssr: false });In my case, I'm using |
Amazing my friend. This is save my time. I spended my time looking for solutions. Thanks man! |
OMG OMG OMG. You are a KING. |
|
That worked for me too: import { BarDatum } from '@nivo/bar';
import dynamic from 'next/dynamic';
const ResponsiveBar = dynamic(() => import('@nivo/bar').then(m => m.ResponsiveBar), { ssr: false }); |
|
Is there anything in the works to fix this? Cause this is a big problem.. |
|
Any fix for us who doesn't use Next but just plain React 18? |
|
@plouc , any hope for this to be fixed? Even dynamically importing the package in NextJs requires compromises (e.g. disabling SSR) which is something undesired. My landing pages shouldn't be having loading stages in them - SSR is very valuable. |
|
The only way I get was install "dependencies": {
...
"victory-vendor": "36.6.11"
},
"overrides": {
"d3-color": "file:../../victory-vendor/lib/d3-color.js"
},But this is workaround, we need an internal solution. |
|
In NextJS 13.4.8 using the app router, the problem went away when I specified |
Have you tried adding this to your remix.config.js |
|
Since upgrading to the recent nivo v0.85.0 release I've been able to reliably use the experimental |
@justshiv, I'm glad to read this! Would you happen to have a small example/public repo available using this config? It seems like it still doesn't solve the issue for some users :( |
|
For people using export default defineConfig({
ssr: {
noExternal: [/^d3.*$/, /^@nivo.*$/],
},
});It basically works around the issue by bundling the packages. My current understanding is that for |
|
@plouc I think going forward you'd have two possible choices.
This means that it won't be possible for any
While is more work for you, I think could be the path of least resistance. By bundling At Prisma, we've used the second option (bundling) to overcome the differences between CJS and ESM but still be able to produce both. Not sure if this is an option for your lib though. |
|
While I would personally really appreciate option 2 (bundle and transpile It is a bit of a pain at the moment but the faster we move towards |
|
I also lean towards the first option, it seems like the community is (slowly 😅) moving forward, and I really don't want to add more complexity to the project. I expect some complains though. |
I have tried this modification in my in my package.json file and i am still getting the following error: Am I missing something? Any suggestions? |
Yes, moving towards an esm future will be the optimal solution imo 👍 Any timeline/ETA 🙃 ?? |
|
@anishLearnsToCode this has worked for me ssr: {
noExternal: ["@nivo/*"],
}, |
|
@plouc Faced this issue today in the project that renders Nivo components on a Node.js Lambda. I suspect the issue is with file extensions: Per Node documentation:
They confirm in the subsequent heading that only bundlers make a distinction based on In my setup I am not 100% sure this is the case and could not manually update 15 packages to make sure. How hard would be to build a branch with such extensions? |
|
I am running into this issue but only when running |
Legend 🕺 |
|
This is what fixed it for me (vite only) vite.config.ts export default defineConfig({
resolve: {
mainFields: ["module", "browser", "jsnext:main", "jsnext"],
},
});As I understand it, this is telling vite to prefer es modules over cjs, when compiling. |
|
Having the same problem with react app created with CRA. None of the solution have worked. I am on 0.87.0. I tried adding overrides and transformIgnorePatterns |
|
There's been mention of discontinuing the const fs = require('fs');
const path = require('path');
// list used nivo packages
const nivoPackages = [
'annotations',
'arcs',
'axes',
'bar',
'calendar',
'colors',
'core',
'legends',
'network',
'pie',
'polar-axes',
'radial-bar',
'recompose',
'scales',
'treemap',
'tooltip',
];
nivoPackages.forEach((package) => {
const filePath = path.join(__dirname, '../', 'node_modules', `@nivo/${package}`, 'dist', `nivo-${package}.cjs.js`);
if (fs.existsSync(filePath)) {
fs.unlinkSync(filePath, (err) => {
if (err) throw err;
console.log(`Deleted: ${filePath}`);
});
}
});
console.info('Nivo CJS files deleted: ', nivoPackages.join(', '));I know there is some contention around the usage of |
@tony-cocco when you're using this, how are you getting around the |
We don't have this issue. Our build grabs the other dist file iirc. Here are some of our module configurations in our I want to add, if you're using nextjs, you likely need to remove your build cache: |
|
Should probably move CJS imports to a different path or deprecate CJS entirely. I wanted to upgrade from v0.80.0 to v0.87.0 to use the new totals feature on bar charts. "@nivo/core": "^0.87.0",
"@nivo/bar": "^0.87.0",
"@nivo/line": "^0.87.0",
"@nivo/pie": "^0.87.0",The above postinstall script worked for me. Here is a tweak I made to make it automatically find which nivo packages you're using. const packageLock = require('../package-lock.json');
const nivoPackages = Array.from(new Set(
Array.from(
JSON.stringify(packageLock).matchAll(/@nivo\/(?<pkg>[a-z0-9_-]+)/gi),
).map((result) => result.groups.pkg),
));And, I did have to clear the build cache with |
Setup
OverviewSeveral of my tests fail with the following error after upgrading from v0.8.0 to v0.8.7 Error: require() of ES Module node_modules/d3-interpolate/src/index.js from node_modules/@nivo/core/dist/nivo-core.cjs.js not supported. Instead change the require of index.js in node_modules/@nivo/core/dist/nivo-core.cjs.js to a dynamic import() which is available in all CommonJS modules. After some extensive research, I stumbled upon this discussion under the Vitest repo. To quote sheremet-va, Vitest has to use Node.js resolution so you don't have multiple instances of the same package, and Node.js doesn't support the module field. This is a problem because Nivo relies solely on the module field in its package.json. "main": "./dist/nivo-bar.cjs.js",
"module": "./dist/nivo-bar.es.js",
"types": "./dist/types/index.d.ts",Whereas the recommended approach is to define package entry points under exports. "main": "./dist/nivo-bar.cjs.js",
"module": "./dist/nivo-bar.es.js",
"types": "./dist/types/index.d.ts",
"exports": {
"require": "./dist/nivo-bar.cjs.js",
"import": "./dist/nivo-bar.es.js",
"types": "./dist/types/index.d.ts",
}WorkaroundsI've tried the following workarounds with success. Please refer to the Vitest discussion for step-by-step instructions. 1) Patch Nivo with exportsUse patch-package and postinstall, as suggested by mkarajohn in the Vitest discussion. I had to patch several Nivo packages with exports. "scripts": {
"patch-nivo": "patch-package @nivo/annotations @nivo/axes @nivo/bar @nivo/colors @nivo/core @nivo/legends @nivo/scales @nivo/tooltip -- exclude 'nothing'",
"postinstall": "patch-package"
}2) Create aliases in vite.config.jsUse aliases, as suggested by deleugpn in the Vitest discussion. resolve: {
alias: {
'@nivo/annotations': '@nivo/annotations/dist/nivo-annotations.es.js',
'@nivo/axes': '@nivo/axes/dist/nivo-axes.es.js',
'@nivo/bar': '@nivo/bar/dist/nivo-bar.es.js',
'@nivo/colors': '@nivo/colors/dist/nivo-colors.es.js',
'@nivo/core': '@nivo/core/dist/nivo-core.es.js',
'@nivo/legends': '@nivo/legends/dist/nivo-legends.es.js',
'@nivo/scales': '@nivo/scales/dist/nivo-scales.es.js',
'@nivo/tooltip': '@nivo/tooltip/dist/nivo-tooltip.es.js',
}
} |
|
I have created a pull request that will allow the nivo package to be treated as an ESM. If this pull request is merged, it will resolve the errors with the modern bundler. |
|
any movement on this? |
|
Hey people, don't know if that's the same but I have a dependabot updating 0.84.0 to 0.87.0 and facing an issue. Getting this error on webpack project while running jest: I checked the changelog but did not find any migration guide about dependencies. |
and others
Related to:
What's the issue?
Users of nivo are experiencing import issues since the release
0.81.0, this is due to a breaking change ind3-color, which was updated due to security issues.Most D3 packages are now esm only and
d3-coloris one of them, other libraries depending on D3 experienced the same problem, victory even wrote a post about this explaining it in details, and visx has an opened issue about it.Nivo provides esm/cjs/umd, but only esm can be supported now due to this change, and it also seems that sometimes people get the cjs version rather than the esm one, that's another thing that needs to be fixed.
What should I do?
0.80.0, as the D3 packages used in this version are not esm only, the drawback is that there are some critical security issues in those. Also0.80.0contains a regression for canvas based components 😓The text was updated successfully, but these errors were encountered: