RepoPilot

chartjs / chart.js

Search chartjs/chart.js

GitHub

Code

Understand chartjs/chart.js's source layout and find a starting point for your task using the saved repository evidence.

Detailed import-graph metrics were not captured for this report.

How the code fits together

AI
  • Public API & Entry PointsMain Chart.js exports and module entry points for different module systems.
  • Chart Types & ControllersChart-type-specific rendering and data handling logic (bar, line, pie, etc.).
  • Core ArchitectureFoundation systems: chart lifecycle, dataset management, plugins, scales, animations.
  • Rendering Primitives & ElementsLow-level visual elements rendered on canvas (arcs, bars, lines, points).
  • Scales & AxesAxis scaling, tick generation, and coordinate transformation systems.

Files at 7169e65147a4 · descriptions are AI-written.

The descriptions and the file list come from different revisions. Check responsibilities against source.

Where to start reading

  1. Repository root
  2. Repository root
  3. Declared package entry
  4. Declared package entry
  5. Declared package entry
  6. Declared package entry

Find files for a task

AI

Add a new chart type

Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.

  • Register the new controller in the registry within src/controllers/index.js
  • Add type definitions to src/types/index.d.ts for TypeScript support

Add a new scale type

Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.

  • Export and register the scale in src/scales/index.js
  • Add tick generation logic if custom ticks needed, referencing src/core/core.ticks.js patterns
  • Update type definitions in src/types/index.d.ts

Add a new plugin

Suggested by the saved analysis. Some step paths were not captured or refer to generated or vendor files; only observed source files are linked.

  • Implement standard hooks (afterInit, afterDatasetsDraw, etc.) matching src/core/core.plugins.js interface
  • Register plugin in src/plugins/index.js exports
  • Add plugin options to default config in src/core/core.defaults.js

Extend chart configuration options

Suggested by the saved analysis. Verify the proposed change against these source files.

  • Define new option in the relevant controller (e.g., src/controllers/controller.bar.js) or core.config.js
  • Add default value to src/core/core.defaults.js
  • Use helper in src/helpers/helpers.options.ts for option resolution
  • Update TypeScript types in src/types/index.d.ts

Change the public API

Start at the entry points declared by the captured manifest, then trace their implementation and tests.

  • Declared by package.json (exports../auto.types). Follow its exports or calls to find the implementation.
  • Declared by package.json (exports../auto.import). Follow its exports or calls to find the implementation.
  • Declared by package.json (exports../auto.require). Follow its exports or calls to find the implementation.

Add or update tests

Use a nearby test as a pattern. Read the root manifest or contribution guide for the correct test command. These suggestions use file names, not verified execution paths.

  • File-name match for this task.
  • File-name match for this task.
  • File-name match for this task.

Change build or automation

Inspect the relevant configuration and the commands it runs before changing the workflow. These suggestions use file names, not verified execution paths.

  • File-name match for this task.
  • File-name match for this task.
  • File-name match for this task.

File paths come from a snapshot of up to 500 captured paths; an omitted file may still exist.

  • Some manifest entry targets are generated output or are absent from the captured source paths. Their source implementation has not been established.
  • The file list was refreshed after the written analysis. Subsystem descriptions and suggested changes may describe an older revision.

Architecture and request flow

Start here — files every contributor must understand

AI · unverified
1
src/index.ts

Main entry point exporting the Chart class and public API; all consumers depend on this.

2
src/core/core.controller.js

Core Chart controller managing initialization, updates, and lifecycle; foundation for all chart behavior.

3
src/core/core.datasetController.js

Base dataset controller defining how datasets are rendered and updated across all chart types.

4
src/controllers/index.js

Registry and exports for all built-in chart type controllers (bar, line, pie, etc.).

5
src/core/core.registry.js

Plugin and component registration system allowing extensions without modifying core files.

6
rollup.config.js

Build configuration defining how source is compiled to UMD, ESM, and CommonJS bundles.

7
package.json

Workspace root defining monorepo structure with auto and helpers packages.

Request flow

Technology choices

HTML5 Canvas

Native browser API providing high-performance 2D drawing without DOM overhead; allows flexible, pixel-precise rendering.

TypeScript

Provides type safety for complex chart APIs and configuration; aids maintainability in large codebase with multiple extension points.

Plugin Architecture

Decouples built-in features (legend, tooltip, title) from core, reducing coupling and enabling third-party extensions without core modification.

Monorepo (pnpm workspace)

Separates auto-registration and helper packages, allowing flexible bundling strategies for different consumer scenarios (webpack 4, modern bundlers).

Rollup

Produces optimized ESM, UMD, and CommonJS builds from TypeScript/JavaScript source with tree-shaking support.

Build time and runtime

Build-time

  • ▸
    TypeScript Compilation — Compiles .ts sources to JavaScript; produces type definitions for consumers.
  • ▸
    Rollup Bundling — Combines modules into UMD (global + module), ESM, and CommonJS formats with tree-shaking.
  • ▸
    Auto-registration Package Generation — Generates auto.cjs and auto.js wrappers in the auto/ workspace package for legacy bundler support.

Runtime

  • ▸
    Chart Instantiation & Config Parsing — Merges user config with defaults; initializes controllers, scales, and plugins.
  • ▸
    Animation Frame Loop — Orchestrates rendering on each frame via core.animator.js; handles easing and duration.
  • ▸
    Event Handling & Interaction — Routes mouse/touch events to interaction system; tooltips and legend filtering via plugins.
  • ▸
    Canvas Rendering — Draws scales, datasets, and overlays to canvas using element renderers and helpers.

Design trade-offs

Canvas-only rendering (no SVG option)

Canvas provides unified performance characteristics and simpler rendering model; SVG would require separate rendering paths.

Accessibility features (alt text, native selection) require manual implementation; not suitable for highly interactive document-like interfaces.

Global registry pattern (core.registry.js) for chart types and scales

Enables dynamic registration and plugin composition without hardcoding all chart types; simplifies bundler support.

Requires explicit registration step for custom types; less discoverable via static analysis.

Configuration-driven behavior over inheritance-heavy subclassing

Reduces boilerplate and allows runtime behavior changes; more flexible for combinations of features.

Large, nested configuration objects can be difficult to navigate; requires careful defaults management.

Sequential plugin hook execution (not parallel)

Ensures predictable ordering and allows plugins to depend on prior transformations.

Cannot leverage multi-threading; performance depends on hook implementation quality.

Non-goals

  • ✗3D chart rendering (2D canvas only)
  • ✗Real-time data streaming beyond animation frames (no WebSocket helpers)
  • ✗Accessibility compliance built-in (relies on external plugins or manual ARIA)
  • ✗Server-side rendering (browser canvas-dependent)

Code quality and hotspots

Quality Score: 90/100

Low Risk

This repo is in good health with CI, tests, and active maintenance.

High complexity -10

Maintainability grade

Static analysis

How maintainable the code looks — from complexity, code issues, test presence, file size, and hotspot load. It grades the shape of the code, not defect risk, and doesn't replace review.

D
54/100
A ≥ 85, B ≥ 70, C ≥ 55, D ≥ 40, F < 40
Cyclomatic complexityavg 106
0/35
Code issues0 errors, 8 warnings
17/20
Testspresent · ~100% of files
20/20
Largest file1,713 lines
7/15
Hotspot load0 high-risk files
10/10

Configuration status

CI/CD Pipeline — configured

Provider: GitHub Actions

5 GitHub Actions workflows

Test Suite — detected

1,458 test files detected

Where: test/fixtures/controller.bar · test/fixtures/controller.bar/backgroundColor · test

Test Coverage — ~100%heuristic

1,458 test files / 106 source files. This is a file-count ratio, not real line coverage — set up Codecov for authoritative numbers.

Dependency Scanning — 1 tool configured

Dependabot

Top hotspots

Files edited often AND hard to reason about. Churn = recent commit frequency, Complexity = branches and nesting, Risk = both combined. These are the highest-leverage targets for refactoring or testing.

core/core.datasetController.js
Churn: 4 (1 commit/180d)Complexity: 100Risk: 4
elements/element.arc.ts
Churn: 4 (1 commit/180d)Complexity: 100Risk: 4

All hotspots

Files that change often and are complex tend to accumulate more bugs

Code metrics

Static analysis on sampled source files (up to 15 files).

Avg Cyclomatic Complexity106

Counts if/for/while/switch/catch/ternary branches

Errors / Warnings0 / 8

Secrets, empty catches, console.log, var usage, long lines

Largest File Analyzed1713 lines
src/core/core.scale.js