The Problem

Developers need fine‑grained control over SVG, Canvas, and HTML visualisations but often have to choose between heavyweight chart libraries or low‑level primitives that lack documentation. Maintaining a consistent, up‑to‑date reference for D3’s API surface is also cumbersome.

What This Does

The repository ships a curated subset of the official D3 library together with a full documentation site built with VitePress. The runtime entry point is src/index.js, which re‑exports the public modules. Documentation lives under docs/ (152 Markdown files plus Vue components) and is served by the VitePress theme located in docs/.vitepress/theme/. Build artefacts such as bundle.js and the Rollup config (rollup.config.js) produce a single distributable bundle.

How It Is Wired

Execution starts at src/index.js. This file imports the core D3 modules and exposes them for consumers; the static import graph shows it has 2 incoming imports and 0 outgoing imports, giving it an instability of 0 (the most stable node). The only other import edges are:

  • bundle.js → (imports) one internal module, instability 1.
  • test/d3-test.js → (imports) one internal module, instability 1.

No circular dependencies exist. The documentation site boots from docs/.vitepress/theme/index.ts, which pulls in the custom layout components (CustomLayout.vue, ExamplesGrid.vue, etc.). These Vue components render the Markdown pages and interact with helper scripts like docs/components/PlotRender.js. The test suite (test/d3-test.js, test/docs-test.js) validates both the library export surface and the documentation build, but the import graph does not show deeper runtime wiring beyond the entry points.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/d3
cd d3

# Install dependencies (yarn lockfile present)
yarn install

# Build the library bundle
yarn run build   # uses rollup.config.js → produces bundle.js

# Serve the documentation locally
yarn run docs:dev   # VitePress dev server (entry: docs/.vitepress/theme/index.ts)

No additional configuration files (e.g., .env) are required. The primary runtime artefact is the bundled script bundle.js, which can be imported by downstream projects.

Real‑World Use

A data‑science platform can embed the compiled bundle.js in a web UI to render custom charts. Example integration:

<script type="module">
  import * as d3 from './bundle.js';
  const svg = d3.select('#chart')
                .append('svg')
                .attr('width', 600)
                .attr('height', 400);
  // draw a simple bar chart …
</script>
<div id="chart"></div>

The platform can also point its help centre to the VitePress site generated from the docs/ folder for up‑to‑date API references.

Code Health & Issues

  • MEDIUM – GITHUB_TOKEN least‑privilege not declared (.github/workflows/test.yml).
  • MEDIUM – No Dependabot/Renovate bot (package.json present, no config).
  • MEDIUM – No dependency‑vulnerability scan in CI (.github/workflows).
  • MEDIUM – persist-credentials: false missing on checkout (.github/workflows/deploy.yml).
  • LOW – No job timeouts set (.github/workflows/deploy.yml).

Additional measured findings:

  • MEDIUM – Duplicated 6‑line code blocks across four Vue examples (ExampleCollideForce.vue, ExampleLinkForce.vue, UsMap.vue, WorldMap.vue).
  • MEDIUM – Oversized prebuild.sh (686 lines) – hard to maintain.
  • MEDIUM – High branching density in test/docs-test.js (17 branches in 60 lines).

All findings are derived from static analysis; no structural red flags were detected beyond the items listed.

The Bottom Line

The repo delivers a functional D3 bundle and a comprehensive VitePress documentation site, but the codebase shows moderate technical debt (duplicate Vue snippets, a monolithic build script) and lacks essential CI hardening (least‑privilege tokens, dependency scanning). It is suitable for teams that need a self‑hosted D3 reference and are prepared to address the identified maintenance and security gaps.