d3-selection-multi + default d3 doesn't play well with bundlers

[d3]

d3-selection-multi + default d3 doesn't play well with bundlers

[mbostock]

Specifically, the default resolve.packageMains (resolve.mainFields in v2) should probably be changed to:

["webpack", "module", "browser", "web", "browserify", ["jam", "main"], "main"]

At least, assuming that Webpack is configured to take ES modules as input.

[hosseinzoda]

Though import * as d3 from "d3"; works fine. Probably it's fine to leave it alone.

[mbostock]

Sorry, but I don’t have familiarity with Webpack so I can’t comment on what is necessary to get it to work. Ideally, there’s a way to tell Webpack to observe the module entry point defined in the package.json.

[hellochar]

Sorry - what I'm suggesting is to build a d3-selection-multi.js and a d3-selection-multi.node.js just like d3, where d3-selection-multi.js only require("d3"), while d3-selection-multi.node.js does the current behavior. Then, pointing "browser" to d3-selection-multi.js and "main" to d3-selection-multi.node.js. Thoughts?

[mbostock]

This package doesn’t depend on d3; it depends on d3-selection and d3-transition.

[hellochar]

Are you saying that if a user does:

var d3 = require("d3");
var d3Selection = require("d3-selection");

The expected behavior is that they get two separate instances of d3-selection - one from the bundled "d3", and one from "d3Selection"? That doesn't sound right since d3 is just supposed to be a re-export of the different modules, but that's exactly what's happening now.

[mbostock]

They get one; that’s why d3.node.js exists, and why d3’s package.json has separate browser and main entry points.

[mbostock]

My point is that Webpack shouldn’t be using the browser entry point. It should be using the module entry point.

[hellochar]

Agreed, but the definition of the browser entry point is specifically to hint to bundlers which file to use. So I think my main issue is that d3's browser tells webpack to use the prebundled one, instead of the d3.node one that has imports proper.

[mbostock]

The browser entry point also affects unpkg, so that when you load d3 from a browser, you get the browser version and not the Node version.

<script src="https://unpkg.com/d3"></script>

Again, Webpack should be using the module entry point, giving that precedence over the browser entry point (and finally falling back to main if neither of those are specified).

[hellochar]

You're right, webpack 2's mainFields addresses this with the "target" property (e.g. target: "node" vs target: "web"). I think that makes sense. The only remaining gripe is that consumers still have extra webpack configuration... might just copy/paste the source instead. Anyways, thanks for walking through that with me. Cheers!

[hosseinzoda]

@mbostock I figured out why importing d3 with webpack returns undefined. Though i don't have time to submit a PR. Since i need to prepare dev env for d3.

At the end of d3.js, or when it gets transpiled to ES5. There's this line.

Object.defineProperty(exports, '__esModule', { value: true });

And there's import default thing in webpack. Which wraps all require calls with a call to this function,

function _interopRequireDefault(obj) {
  return obj && obj.__esModule ? obj : {
    default: obj
  };
}

And then webpack uses d3.default after my code is packed. like this.

var _d = _interopRequireDefault(__webpack_require__(/*! d3 */ "./static/components/d3/d3.js"));
console.log(_d.default);

My code was.

import d3 from "d3";
console.log(d3);

So the problem is that .default is not defined. Either you need to have export default d3. where d3 is defined and contains all outputs. Some way to set. exports.default = d3;
Or do not have .__esModule true.

I'm not familiar with export default syntax. And the reason why it's required for modules ES6 modules.
Maybe the problem is in my webpack config.