Blueprint Colors

Official color constants and Sass variables powering Blueprint's design system, in modern and legacy palettes.

Library
npm
v5.1.16
22,033stars
Apache License 2.0

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
97/100Excellent
Development Activity100
Maintenance96
Community92
Maturity60
Momentum40

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
68/100Good
Architecture65
Code Quality55
Innovation80
Learning Curve70

@blueprintjs/colors packages the color palette that backs every Blueprint UI component into a small, standalone module. It exports a Colors object with five-step gray, core, and extended hue scales tuned for accessible contrast, plus a deprecated LegacyColors object preserving the original Blueprint 3.x palette for teams still migrating off it. The same values are also generated into a _colors.scss partial, so Sass-based styles and TypeScript/JavaScript consumers stay in sync from one source of truth.

Because it has no runtime dependency beyond tslib, the package can be installed on its own to reuse Blueprint’s palette in a design system, a tokens pipeline, or an unrelated UI kit without pulling in any of Blueprint’s React components.

What You Get

  • A Colors object with BLACK/WHITE, a five-step gray scale, and BLUE/GREEN/ORANGE/RED core hues plus ten extended hues (CERULEAN, FOREST, GOLD, and more), each as a 1-5 shade ramp.
  • A LegacyColors object preserving Blueprint 3.x’s original hue values for apps mid-migration to the modern palette.
  • A generated _colors.scss partial exposing every color as a !default Sass variable, kept in lockstep with the TypeScript source via the repo’s generate-css-variables build script.
  • CommonJS, ESM, and ESNext builds plus bundled .d.ts typings, so the same package works in Node, bundler, and tree-shaking contexts.

Common Use Cases

  • Theming a custom component library with Blueprint’s accessible color ramps without adopting Blueprint’s React components.
  • Importing Colors in TypeScript/JS code to keep chart, icon, or canvas-drawn colors visually consistent with the rest of a Blueprint-based app.
  • Importing _colors.scss variables directly in Sass stylesheets for custom CSS that needs to match Blueprint’s palette.
  • Falling back to LegacyColors while incrementally migrating a large app from Blueprint 3.x styling to the modern 4.x+ palette.

Under The Hood

Architecture The package has no runtime logic to speak of: src/colors.ts builds three flat objects (grayScale, coreColors, extendedColors) and merges them with a small set of named constants into the single Colors export, while src/legacyColors.ts defines the parallel LegacyColors object for the 3.x palette; src/index.ts simply re-exports both. The one real architectural decision is keeping this palette in its own package, decoupled from @blueprintjs/core, so any consumer can depend on the color tokens alone; changing a hue value here has zero risk of touching component logic, only visual output for every downstream Blueprint package and app.

Tech Stack Written in TypeScript and compiled three ways (tsc to CommonJS and ESNext, plus a separate ESM pass) via the monorepo’s shared build scripts, with tslib as the only runtime dependency. Color values are additionally rendered into Sass through the workspace’s own generate-css-variables CLI (from @blueprintjs/node-build-scripts), which reads the same TypeScript source and emits _colors.scss with !default variables, plus sass-compile/sass-lint for the Sass side and es-lint for the TypeScript side.

Code Quality No test files exist in this package (an intentional choice, since the module is data with no branching logic), so quality guarantees come entirely from TypeScript’s type checking on the exported constant shapes and from workspace-level ESLint/stylelint rules (including a custom no-color-literal stylelint rule elsewhere in the monorepo that forces other packages to reference these variables rather than hardcoding hex values). Naming is consistent and mechanically generated (uppercase constant keys, numbered 1-5 shade suffixes), leaving little room for typos or drift.

API Design The public surface is intentionally tiny: two named exports, Colors and LegacyColors, both plain object literals with no functions, factories, or configuration to learn. A JSDoc @deprecated tag on LegacyColors documents the migration path inline, and the parallel Sass file mirrors the same variable names so a developer moving between TS and SCSS never has to relearn a naming scheme. Getting started requires a single import and zero setup.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search