import conflict with 3.0.0 update

Hi! I happened to pull in v3.0.0 of d3-format today and the recent type: “module” change broke an existing use case. I realize it’s a major version bump, and I hate to be a bother, but wanted to report in case it’s not an expected behavior with this change.

I have a very simple set up, entirely reproduced in this repo here. https://github.com/freeman-lab/d3-import-test

It’s a tiny next.js app that depends only on d3-import in one file using the syntax

import { format } from 'd3-format'

Previously with ^v2.0.0 this worked fine. With v3.0.0 I get this error

Error: Must use import to load ES Module: /Users/freeman/github/freeman-lab/d3-import-test/node_modules/d3-format/src/index.js
require() of ES modules is not supported.
require() of /Users/freeman/github/freeman-lab/d3-import-test/node_modules/d3-format/src/index.js from /Users/freeman/github/freeman-lab/d3-import-test/.next/server/pages/index.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename /Users/freeman/github/freeman-lab/d3-import-test/node_modules/d3-format/src/index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from /Users/freeman/github/freeman-lab/d3-import-test/node_modules/d3-format/package.json.

I’m not an expert on some of the recent module ecosystem preferences, so I’m not totally sure how to think about the problem.

I did confirm that I could get it to work by putting "type": "module" in the top-level package.json of my app. But that then made it impossible to use many other modules, including all the d3-* modules that have not yet been updated. And of course everything also worked if I rolled back to ^v2.0.0, but then I’m stuck with older versions.

So, is my understanding correct that using any of the new versions of the d3-* modules will force the "type": "module" requirement on the importing module as a whole? Or am I importing incorrectly?

Again, apologies if I’m misunderstanding, this might all be intended behavior and I just need to change the usage pattern on my side.

Thanks for all the hard work you do on these libraries!

[mbostock]

This is an issue with Next.js, not with D3, so closing. You can either stick with the previous major version, workaround it as described below, ask the Next.js team to fix it, or contribute a fix to Next.js.

I believe the workaround for Next.js involves putting something like this in your next.config.js:

function generateIncludes(modules) {
  return [
    new RegExp(`(${modules.join("|")})$`),
    new RegExp(`(${modules.join("|")})/(?!.*node_modules)`)
  ];
}

const includes = generateIncludes([
  "d3-format" // list any other ES module packages here
]);

module.exports = {
  webpack: (config, options) => {
    config.externals = config.externals.map((external) => {
      if (typeof external !== "function") return external;
      return (context, request, callback) => {
        return includes.find((i) =>
          i.test(
            request.startsWith(".") ? path.resolve(context, request) : request
          )
        )
          ? callback() // i.e., not an external
          : external(context, request, callback);
      };
    });
    return config;
  }
}; 

[cruikshankss]

Got lucky today. Updated Node version (by clicking the installer on their website) and Next.js version to latest (by yarn add next@latest). No longer have the error. Seems that Next.js team supports ESM modules now needed for import * as d3 from 'd3'. Good luck out there!