Add sideEffects: false to package.json.

Hello D3 Family!!! @TheLarkInn from webpack here!

We have been working on a new feature for webpack 4+ which allow’s library authors to add a special field to package.json allowing them to declare that their libraries that have “reexports” in them do not contain side effects!

Tiny Backstory

Because webpack implements the Harmony Module Specification to spec, we include code that was reexported (even if it wasn’t used). This is because all code [per spec] must be eval’d). The beautiful news is that we do not have to implement exactly to spec. So we have created what is called “pure-module”. webpack as imports are being resolved will also check to see if the module is pure (which is indicated through the pure-module flag in the package.json fields). Therefore, there would be no bundle size difference between the following examples:

import {bottomAxis} from "d3-axis";

and

import bottomAxis from "d3-axis/direct/path/to/d3AxisBottom"

Proposal

If there are no side-effects within the D3 packages in places where re-exports occur, then I’d love to propose that all D3 packages add pure-module: true to their package.json.

Pros

Developers (using webpack) get huge perf wins by doing nothing.

Cons

Bit more work to get it all done.

Please let me know if you have any questions, the webpack team is really anxious to help in any way if we can (that means, submitting PR’s, adding issues to individual repo’s to track, etc).

sideEffects: true

• d3-format (src/defaultLocale.js)
• d3-time-format (src/defaultLocale.js)
• d3-transition (src/selection/index.js)

sideEffects: false

• d3
• d3-array
• d3-axis
• d3-brush
• d3-chord
• d3-color
• d3-contour
• d3-delaunay
• d3-dispatch
• d3-drag
• d3-dsv
• d3-ease
• d3-fetch
• d3-force
• d3-geo
• d3-hexbin
• d3-hierarchy
• d3-interpolate
• d3-path
• d3-polygon
• d3-quadtree
• d3-random
• d3-scale
• d3-scale-chromatic
• d3-selection
• d3-shape
• d3-tile
• d3-time
• d3-timer
• d3-zoom

[TheLarkInn]

How can we test that it is working as intended?

For now you could pull down the PR to test it out. (In the future we are working on webpack-canary which can help us and everyone else test webpack versions/commits/branches against anything they want.

Currently today the behavior is this (I’m using a plugin in VSCode that calculates the cost based on way it is imported):

Larger sized because reexported code is being evaluated and included in bundle even if not used

Smaller sized because importing directly from module w/ no reexports

So with this pure-module change, you will know its working in that you can use either syntax seen above and the size should be representative of the second image. (aka it should be small no matter what for any pure modules).

Most D3 modules should be side-effect free, but I know of at least a few places that are not, and I don’t know whether there is a way to restructure them to make them “pure”.

I think there are going to be times where its not really avoidable and that’s totally fine. If that’s the case you can leave the property off for those specific modules and I think that’s totally fine. In terms of suggestions to do it another way, I’m not quite sure what would be the easiest approach or if even possible.

Once webpack-canary is closer to a place where it could be leveraged in lets say unit/functional tests, I’ll let you know, but otherwise if you wanted to try it out earlier you can try and run webpack from this PR.

Let me know if there’s any other ways we can help. When I find some time in the near future, I’ll try and run the PR locally against a modded package.json file for d3 and make sure it is doing the expected behaviors myself. Thank you for the collaboration. This is going to be an awesome out of the box perf win when people use d3 with webpack 4 and that’s what excites me the most.

[TheLarkInn]

Here is a better explanation that I provided for a user on Stack Overflow. Please let me know if this answers your questions.

https://stackoverflow.com/a/49203452/1624684