Bootstrap's main branch is a year ahead of the version its quick start pins

The default branch has moved a year past the tag the readme installs

The quick start pins a version in every command, for example `npm install [email protected]`, `yarn add [email protected]`, `bun add [email protected]`, and `composer require twbs/bootstrap:5.3.8`, and the download link points at the v5.3.8 archive. That tag was published on 26 August 2025, preceded by v5.3.7 in June 2025 and v5.3.6 in May 2025. The last push to main is dated 25 September 2026. Consequence for a reader: the two ways of getting the project diverge, because a package manager install gives you the year-old release while a clone gives you main, which is a year of unreleased work. A third detail reinforces the gap, package.json carries a separate config value version_short set to 5.3, so the documentation URLs at getbootstrap.com/docs/5.3/ are versioned at minor granularity while the package is at patch granularity.

Six install routes pin 5.3.8 and the seventh cannot

Quick start offers seven options. Downloading the release archive, cloning with `git clone https://github.com/twbs/bootstrap.git`, and installing through npm, yarn, Bun, or Composer all name the version explicitly. The NuGet line does not, and it is also the only one that splits into two packages:

CSS: Install-Package bootstrap
Sass: Install-Package bootstrap.sass

So the CSS build and the Sass sources are separate NuGet packages, and neither is versioned in the command the readme gives you. Consequence for a reader assembling a reproducible build: five of the six language routes pin 5.3.8 and the sixth takes whatever the feed considers current, so a NuGet-based pipeline drifts from the documented version with no edit on your part. If you want the Sass sources through that channel you also have to add a second package, and mixing the CSS package with the Sass package is a decision the readme does not walk you through.

Popper is bundled only in the two bundle files

The compiled output explanation is precise about which files carry a dependency. Compiled CSS and JS ship as bootstrap.* with a minified bootstrap.min.* variant, source maps ship as bootstrap.*.map, and then there is the exception: the bundled JS files, bootstrap.bundle.js and the minified bootstrap.bundle.min.js, include Popper. Nothing else does. Consequence for a reader: the dist layout is built to let you take pieces, with separate grid, reboot, and full builds in both LTR and RTL, and the natural instinct is to import the component you need. If you do that from the non-bundle file, Popper is absent and you get a runtime failure inside the component rather than a build error, because the import resolved fine. The readme points at the Popper documentation but does not state the rule as a rule, so the distinction is easy to miss.

RTL is a separate generated pass with its own exclusion globs

RTL is not a build flag you set, it is a fourth step in a pipeline. The css target is:

"css": "npm-run-all css-compile css-prefix css-rtl css-minify"

The rtl step runs postcss with NODE_ENV=RTL and an explicit file set, and its two negative patterns matter:

"css-rtl": "cross-env NODE_ENV=RTL postcss --config build/postcss.config.mjs --dir \"dist/css\" --ext \".rtl.css\" \"dist/css/*.css\" \"!dist/css/*.min.css\" \"!dist/css/*.rtl.css\""

The result is that dist holds bootstrap-grid.rtl.css and bootstrap-reboot.rtl.css as separate files alongside the LTR ones. Consequence for a reader: because RTL is a duplicate file rather than a mode, a build step that globs *.css picks up both directions and you must exclude one yourself, and because the four css steps are ordered, running a subset leaves you without minified output or without RTL output while the dist directory still looks populated.

The Sass step is explicitly told not to fail on CSS errors

The compile command is:

"css-compile": "sass --style expanded --source-map --embed-sources --no-error-css scss/:dist/css/"

That fourth flag is the notable one. With --no-error-css a malformed declaration does not abort the build, so the command exits having written files and your dist directory looks freshly generated. The other guard is not much harder, since css-lint runs npm-run-all with --continue-on-error and in parallel:

"css-lint": "npm-run-all --aggregate-output --continue-on-error --parallel css-lint-*"

The linters it fans out to are stylelint over all css and scss files with a cache at .cache/.stylelintcache, and fusv over the scss and site scss directories. Consequence for a contributor or a build owner: two consecutive soft failures, a compile that tolerates bad CSS and a lint pass that continues past errors, mean a clean-looking dist is not evidence of correct CSS. The size side is guarded separately, with bundlewatch reading .bundlewatch.config.json, so bloat is caught even when correctness is not.

The docs need a rebuild before they will show current CSS

Running the documentation locally takes four steps and the order matters. Run `npm install` for the Node dependencies including Astro, run `npm run test` to rebuild the distributed CSS and JavaScript files as well as the docs assets, then from the root bootstrap directory run `npm run docs-serve`, then open http://localhost:9001. Two things follow. First, a test script is being described as a build step, which is an unfortunate name for anyone who expects it to only run assertions, and skipping it leaves the docs rendering whatever dist files were already there. Second, the port is fixed at 9001 rather than left to a dev server default, so a second checkout on the same machine collides. For day to day work the start script runs both halves at once:

"start": "npm-run-all --parallel watch docs-serve"

Docs search is served by Algolia DocSearch, so a local build still reaches out to a hosted index.

Bootstrap 4 sits on its own branch and JavaScript patches require tests

The default branch is for Bootstrap 5 development, and the readme sends anyone who needs the previous major to the v4-dev branch for its readme, documentation, and source. So the repository holds two maintained lines and the one you get by default is the newer one only. The contribution rules are equally specific in one direction. A pull request containing JavaScript patches or features must include relevant unit tests, and the tests live under js/tests. All HTML and CSS must conform to the Code Guide maintained by Mark Otto, and editor preferences come from .editorconfig. Consequence for a contributor: a JavaScript change without tests is not merely discouraged but explicitly out of bounds, and no equivalent test requirement is stated for a CSS-only change, so the gate on styles is a lint pass and a human reviewer rather than a test suite. For issues, the expectation is to read the guidelines and search existing and closed issues first.

Editorial conclusion

Bootstrap fits someone who wants a grid, a reboot baseline, and prewritten components with an RTL build already produced for them, and who is content to follow a versioned release rather than a moving branch. Decide which you are installing before you start: the readme's quick start pins v5.3.8, the newest release, while main has moved on and the last push is dated 25 September 2026 against a v5.3.8 tag from 26 August 2025, so a clone and a quick start give you different code. Add Popper yourself if you import individual components, since only the bundle files include it. Treat the dist output as unverified until you run the linters, because the Sass step passes --no-error-css and the CSS lint passes --continue-on-error. Use the NuGet route only if you accept an unpinned version. If you are still on Bootstrap 4, switch to the v4-dev branch, since the default branch carries only Bootstrap 5.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes