Blueprint Colors
Official color constants and Sass variables powering Blueprint's design system, in modern and legacy palettes.
Repository Health
Technical Analysis
@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
Colorsobject 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
LegacyColorsobject preserving Blueprint 3.x’s original hue values for apps mid-migration to the modern palette. - A generated
_colors.scsspartial exposing every color as a!defaultSass variable, kept in lockstep with the TypeScript source via the repo’sgenerate-css-variablesbuild script. - CommonJS, ESM, and ESNext builds plus bundled
.d.tstypings, 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
Colorsin TypeScript/JS code to keep chart, icon, or canvas-drawn colors visually consistent with the rest of a Blueprint-based app. - Importing
_colors.scssvariables directly in Sass stylesheets for custom CSS that needs to match Blueprint’s palette. - Falling back to
LegacyColorswhile 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.