Lightweight Charts v5.2.1 and a licence clause that puts a link on your chart

One dependency, pinned exactly, and Node 22.3 to build it

The manifest is small in a way that is worth reading closely. There is exactly one runtime dependency, fancy-canvas at version 2.1.0, pinned to an exact version rather than a range. The files list publishes dist/ and nothing else, and the rollup plugins, the size-limit tooling and the memory testing packages never reach your node_modules. The build side has its own floor: engines asks for Node 22.3 or newer, which applies to anyone building from source and to the plugin workspace, not to the browser that runs the result. The exports map is the part that bites first. It has three conditions, development, production and default, and development points at a different file from the other two, so a bundler resolving the development condition hands your page a different build of the same version. That is a deliberate switch, and it means the bundle you test is not always the bundle you ship.

Four build variants, and only the standalone ones work from a script tag

The variant table is two axes. Mode is PROD or DEV, and the question is whether dependencies are included. Without bundled dependencies you get lightweight-charts.production.mjs and lightweight-charts.development.mjs as ES modules, and the IIFE column reads N/A, because an IIFE with no bundled dependency cannot resolve its import at runtime in a browser. With dependencies included, marked standalone, you get both an .mjs and a .js for each mode, and the .js is what you put on a CDN. The standalone build is also the one that defines window.LightweightCharts, carrying every export from the ES module version behind that object, so a page with no bundler at all can call createChart and addSeries. The cost of that convenience is size, since the standalone build carries fancy-canvas inside it, and the badges at the top of the file track npm bundle size and dependency count as a pair, which is the project's way of saying both are budgeted.

There are two ways to install, and the second one is not a release

The documented installs differ in kind, not just in convenience. The stable route is a single package from npm:

npm install lightweight-charts

The second route exists so you can try the latest master build without waiting for a release, and it is powered by pkg.pr.new:

npm install https://pkg.pr.new/lightweight-charts@master

Nothing about that URL names a version, so what lands in your lockfile is a moving target that a rebuild can replace, and a bug you report against it may not exist in the release you deploy. If you take it, pin the resolved commit yourself. The usage shape is the same either way, and it is worth internalising because v5 moved the series out of the chart constructor:

import { createChart, LineSeries } from 'lightweight-charts';

const chart = createChart(document.body, { width: 400, height: 300 });
const lineSeries = chart.addSeries(LineSeries);

A series type is a value you pass to addSeries, not a method on the chart, which is the shape an assistant trained on v4 will get wrong.

The licence requires naming TradingView and linking tradingview.com

This is the clause that decides whether you can use the library at all, and it is not boilerplate. Alongside the Apache License, Version 2.0, the project states that the licence requires specifying TradingView as the product creator, and that you shall add the attribution notice from the NOTICE file and a link to tradingview.com to a page of your website or mobile application that is available to your users. The project asks, as thanks, for the link in a prominent place. There is a mechanism for the link requirement rather than only the obligation: the attributionLogo chart option renders an appropriate link to tradingview.com on the chart itself, and using it satisfies the requirement. The rest of the licence is the standard Apache 2.0 text, and the file also records that the software incorporates parts of tslib from Microsoft under the BSD Zero Clause License.

The bundled skills exist because v5 snippets in the wild are wrong

The repository ships two Agent Skills for AI coding assistants, hosted in .github/skills and for AI coding assistants such as Claude Code and Codex. The stated reason is that they give an assistant current v5 knowledge to work from instead of outdated snippets it may remember from training, which is an unusual admission to find in a README and a useful signal about how much the API moved. The first skill, lightweight-charts, is about using the library: v5 API conventions, the mental model, and the foot-guns around time, scale, markers, plugins and wrappers. The second, lightweight-charts-plugin-authoring, is about writing a plugin, and it helps choose between a custom series and a primitive, points at @tradingview/lwc-toolkit as the base, and warns about the autoscale, whitespace and hit-test traps. Both install with one command, and --skill <name> picks one:

npx skills add tradingview/lightweight-charts

If you are migrating from v4, the API difference is the project, and this is where the project says so.

Plugins version on their own calendar, separate from the library

The repository is a workspace, not a single package. pnpm-workspace.yaml and pnpm-lock.yaml sit at the top level next to packages/, plugin-examples/, indicator-examples/ and website/, and the contributing path is pnpm even though consumers install with npm. The release tags show the consequence. The library moves on semantic versions, v5.2.0 on 2026-04-24 and v5.2.1 on 2026-08-12, while the plugin packages have their own dated tag, plugins-2026-09-16, described as Plugin packages. Two release streams, two cadences. The extension story is otherwise well served: a plugin catalog of ready-made plugins, interactive examples, and the option to write your own, which is the intended route for anything the built-in series types do not cover, from indicators to drawing tools.

The performance claim is enforced by a size gate in the repo

The claim that the library is one of the smallest and fastest financial charts is backed by configuration rather than adjectives. There is a .size-limit.js at the root and both @size-limit/file and @size-limit/webpack in the development dependencies, so a size budget is something the build can fail on. Memory behaviour is treated the same way, with @memlab/api and @memlab/core in the toolchain, which is how a charting library that paints thousands of points checks for leaks. The type surface is generated and checked separately from the source: dts-config.json and tsdoc.json sit beside a set of six tsconfig files covering composite, options, production and watch modes, and a .puppeteerrc.cjs plus a debug/ directory suggest the visual side is verified in a real browser. If you are contributing, expect CI in .circleci to be the arbiter, and expect the size gate to be part of it rather than a later optimisation ticket.

Canvas is the rendering target, so the DOM is not there to help you

The description says the charts are built with HTML5 canvas, and everything the project adds on top of that follows from the choice. A canvas is a bitmap surface, so the chart is not inspectable as DOM, not selectable as text, and not reachable by a screen reader through the elements the library creates. The extension mechanism the README describes is plugins. The performance argument and the accessibility question are the same decision seen from two sides.

Editorial conclusion

Lightweight Charts fits a product that needs fast interactive price charts and does not want a charting framework in its bundle. It does not fit a team that cannot display a TradingView link, or one that needs the DOM-level accessibility a canvas renderer does not provide by itself. Before you adopt it, read the licence section rather than the badges, because the Apache 2.0 grant arrives with a requirement to specify TradingView as the product creator and to show an attribution notice and a link on a page your users can see, which the attributionLogo chart option can satisfy on the chart itself. Then pin your version, because the second install path ships master rather than a release, and check the exports conditions, since a development build and a production build are different files with different contents.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. tradingview/lightweight-charts on GitHub