Improve tree-shaking

Open
#217 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
javascript, node.js, rollup

Research direction

Read the package build configuration and inspect how it produces dist/d3-shape.mjs; the issue identifies Rollup's output.preserveModules as a possible direction. Run the provided esbuild reproduction to record bundle sizes, then check whether publishing per-module files restores the 3.2.0 behavior while keeping the dist/ layout and bundled CDN builds.

Written by the indexing model from the issue text.

Description

Since 3.2.1, the package's default entry points to one bundled file, dist/d3-shape.mjs, instead of separate source files. sideEffects: false used to let bundlers drop unused files. With one file, importing anything keeps that module, and bundlers then have to prove each top-level statement is safe to remove.

Most of them can't be removed, so importing one curve now pulls in nearly all the others.

Reproduction
npm i [email protected]
echo "export { curveLinear } from 'd3-shape'" \
  | npx [email protected] --bundle --minify --format=esm | gzip -c | wc -c
Import 3.2.0 (gzip) 3.2.1 (gzip)
curveLinear 265 B 2,509 B
arc 2,478 B 4,871 B

Other toolchains are affected too, though less.

Cause

The file has top-level statements that bundlers treat as side effects:

  • 17 prototype assignments, such as Linear.prototype = { … }
  • calls such as var catmullRom = (function custom(alpha) { … })(0.5) and const sqrt3 = sqrt(3)

The prototype assignments matter most. Adding /*#__PURE__*/ to all 18 top-level calls only reduced the curveLinear case to about 2.3 KB, and those annotations can't be applied to assignments.

Suggested fix

Publish one file per module again, for example with Rollup's output.preserveModules, while keeping the dist/ layout and the bundled CDN builds. This restores the behavior of 3.2.0 without changing the source.

The same build change shipped in d3-array 3.2.5 and d3-time 3.1.1, which grew in the same way under esbuild: ticks + tickIncrement from 420 B to about 1.3 KB, and timeDay + utcDay from 597 B to about 2.7 KB. I haven't looked at the cause in those packages.

Dominant language
JavaScript
Stars
2.5k
Forks
307
Avg merge
4h 16m
Merged PRs (30d)
1

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from d3/d3-shape

All issues in d3/d3-shape

Similar issues

More JavaScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.