Blueprint's setup guide says pnpm 10 while package.json pins 11.3.0

The default branch is develop, and the changelog is not in the repository

Almost every link in the setup instructions points at the develop branch rather than a release tag, including the contribution guidelines, which are read from CONTRIBUTING.md on develop. The README says the changelog and migration guides for major versions live on the GitHub wiki, with the 6.x changelog as the linked page, although the repository also has a CHANGELOG.md at its root.

The consequence is that a plain clone gives you the development line of a toolkit whose published packages are on a 6.x line. Recent releases show that line moving: @blueprintjs/labs at 6.4.8, @blueprintjs/icons at 6.15.0, and @blueprintjs/datetime2 at 3.3.1, all published on November 2, 2026, the same day as the last push to the repository.

So when you need to know what a version changed, start with the wiki the README links, plus the CHANGELOG.md in the tree.

The toolkit targets data-dense desktop screens and says so

The positioning is unusually blunt for a component library. Blueprint is described as a React-based UI toolkit for the web, optimized for building complex, data-dense web interfaces for desktop applications which run in modern browsers, followed immediately by the sentence that this is not a mobile-first UI toolkit.

That statement is the design constraint everything else follows from. The component inventory is a spreadsheet-like scalable and interactive table, a select for picking items from a list, date and time components, icons in both SVG and icon font implementations, a core set of styles and components, and a package of design system color variables. These are tools for a screen full of rows, filters, and forms, where density is a feature.

The cost of choosing on that basis is layout. If your product is mobile-first, you are adopting a toolkit whose defaults assume a desktop viewport, and the fight you will have is with spacing and density rather than with missing components. If your product is an internal console, that assumption is the reason to pick it.

The setup guide and package.json disagree about the pnpm version

The prerequisites line states Node.js v24.11+, pointing at the version in .nvmrc, and pnpm v10.x, pointing at the version specified in package.json. The root manifest is named @blueprintjs/root, is private at version 0.0.0, and declares its package manager as [email protected].

Those two statements cannot both be current, and the consequence depends on which one wins on your machine. The documented activation step is `corepack enable`, which makes corepack responsible for the package manager binary, and corepack reads the packageManager field. So in practice the field pins 11.3.0 while the prose still says 10.x, and anyone who reads the prose and installs a pnpm 10 by hand is running a version this repository does not declare.

Resolve it the cheap way: check the packageManager field in package.json before you install anything. Where the two conflict, the manifest is the machine-readable source and the sentence is the stale one.

The Windows setup edits your global npm configuration

The one-time setup is short enough to read as a checklist. Install nvm, then run `nvm use` to pick the supported Node version, then `corepack enable` to activate pnpm, then `pnpm install` for all monorepo dependencies. There is a specific failure hint for that last step: if you see an error beginning with Error when performing the request, the cause may be a VPN that needs to be disabled for the install to succeed.

The Windows branch is the part with lasting consequences. It asks you to run `npm install -g windows-build-tools` for the native build tools, and then to make bash the script shell:

npm config set script-shell "C:\\Program Files\\git\\bin\\bash.exe"

That is a global npm setting, and the guide does tell you how to undo it with `npm config delete script-shell`. Skip the undo and every npm script on the machine, in every project, runs under that bash, which is the kind of change that surfaces much later as an unrelated failure.

pnpm verify is documented as erroring on a working machine

Step five of the setup is `pnpm verify`, described as the way to ensure all the build tooling is working properly. The next line undercuts it: there may currently be some errors when running this step even though everything is set up properly, with a link to issue 6926 for more information.

That caveat changes what the command means. Its exit status cannot be your signal, because a correct setup is expected to produce errors, and a red run is indistinguishable from a real problem unless you read the issue. Step six, marked optional, is the honest check instead: `pnpm dev:demo` starts the demo application, the playground that renders many components on one page in light and dark themes, so a working setup is something you see rather than something you read off an exit code.

Use verify to rebuild tooling when you are not sure, and use the demo app to decide whether your environment is correct.

pnpm compile is the fast catch-up and it skips apps and tests

The guide has a separate section for what to do after pulling new code from develop, and it is more useful than the first-time setup. If package dependencies changed, run `pnpm install` at the root, which the text notes is very quick when there is nothing new to install. Then run `pnpm compile` to get the latest built versions of the library packages in the repository.

The reason to prefer it is stated: compile is quicker than verify because it does not build the application packages, docs-app and landing-app among them, and does not run tests. So a green compile tells you the libraries rebuilt. It tells you nothing about whether the documentation site builds, whether the table component still renders, or whether the suite passes.

The consequence for daily work is that compile is the right command after a pull and verify is the right command when something is broken, and treating a fast compile as full verification is how a broken docs site reaches the gh-pages deploy.

Every dev script drags the docs app along with it

There are two levels of watch mode. `pnpm dev` at the root watches changes across all packages and runs the docs application with webpack-dev-server, and the root script excludes the landing app and the table dev app. Below that, each library has its own script, and the mapping is not one to one: `pnpm dev:core` runs core, icons, and the docs app; `pnpm dev:docs` runs the docs app and the docs theme; `pnpm dev:datetime` runs datetime, datetime2, and the docs app; `pnpm dev:select` runs select and the docs app; `pnpm dev:table` runs table and the table dev app.

Since dev:core, dev:docs, dev:datetime and dev:select each include the docs app, running two of them at once starts the docs app's dev task twice. The guide's recommended workflow answers exactly this: open separate terminal windows or splits and run the local package dev task in each one.

The same script list also reveals something the package overview does not mention. The dev:datetime task references a package named @blueprintjs/datetime2 alongside @blueprintjs/datetime, so there are two datetime packages in the workspace while the library list names only one.

Build tooling ships as packages, so the lint rules follow you out of the monorepo

The third category of packages exists to be consumed elsewhere, and the stated reason is that other Blueprint-related projects should be able to use this infrastructure outside the monorepo. That includes @blueprintjs/eslint-config, used in this repository and recommended for Blueprint projects, @blueprintjs/eslint-plugin and @blueprintjs/stylelint-plugin, which implement custom rules that enforce best practices for Blueprint usage, @blueprintjs/webpack-build-scripts for webpack configuration, @blueprintjs/node-build-scripts for building Sass sources, linting Sass and TypeScript, generating Sass and Less variables, and optimizing icon SVGs, plus a documentation theme, test utilities, and shared test helpers.

The consequence is a choice with teeth. Install the plugin packages and your project inherits rules written specifically for Blueprint usage, so lint output will point at Blueprint conventions rather than at general JavaScript mistakes. Skip them and you keep the components without the guardrails the maintainers use. Pick deliberately, and if the rules disagree with a pattern your codebase already has, expect to spend a day on exceptions instead of on features.

The repository also ships pre-commit hooks through .husky, a storybook configuration, browser targets in .browserslistrc, and a site directory that is assembled by copy scripts and published with gh-pages.

Editorial conclusion

Blueprint fits internal tools and desktop web applications where tables, filters, and dense forms are the work, and it is the wrong pick for a mobile-first product because the project states it is not one. Before you start, read package.json rather than the setup prose, since it pins pnpm 11.3.0 while the guide says pnpm 10.x, and treat pnpm verify as advisory because the guide warns it may error on a correctly configured machine. Use pnpm dev:demo as your real setup check, and expect to run pnpm compile rather than verify when you catch up with develop.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. palantir/blueprint on GitHub
3. Project website
4. README
5. Releases