Bootstrap on main is now 6.0.0-alpha.1: what the twbs/bootstrap repository ships and where v5 users should look

The main branch is Bootstrap 6 alpha, not the release most sites run

The default branch of twbs/bootstrap is main, and it is used for development of Bootstrap 6. The package.json on that branch reports version 6.0.0-alpha.1 with a short version of 6.0, and the docs link at the top of the repository points to getbootstrap.com/docs/6.0/. The newest tagged releases in the GitHub release list are v5.3.8 (2025-08-26), v5.3.7 (2025-06-17) and v5.3.6 (2025-05-05). Source code, readme and documentation for Bootstrap 5 sit on a separate branch called v5-dev.

The consequence for readers is direct: a developer who lands on the repository home page, copies an install line and searches for Bootstrap 5 help will be mixing an alpha package with documentation for a different major version. If your project is on v5, bookmark the v5-dev branch and the versioned docs archive at getbootstrap.com/docs/versions/ rather than the main branch. The repository itself is not dormant: the last push landed on 2026-11-02.

Every package manager line pins 6.0.0-alpha.1, except NuGet

The quick start options on main all target the alpha. Cloning gives you the development branch:

git clone https://github.com/twbs/bootstrap.git

The npm, yarn and Bun lines pin the exact prerelease:

npm install [email protected]
yarn add [email protected]
bun add [email protected]

PHP projects get the same pin through Composer:

composer require twbs/bootstrap:6.0.0-alpha.1

NuGet is the odd one out. It splits the package into a CSS flavor and a Sass flavor, and neither command names a version:

Install-Package bootstrap
Install-Package bootstrap.sass

That means a .NET project and a Node project following the same page can end up on different major versions without anyone noticing. Read the resolved version out of your lockfile or package list after installing. The direct download link on main is an archive named v6.0.0-alpha.1.zip, so the zip route is also the alpha.

Compiled, minified and partial stylesheets in the download

The download is split into css/ and js/ folders. On the CSS side there are four families, each shipped as an expanded file, a minified file and a source map for both: bootstrap.css is the full framework, bootstrap-grid.css carries the grid, bootstrap-reboot.css carries the base reset layer, and bootstrap-utilities.css carries the utility classes. File names follow one convention: bootstrap.* is compiled, bootstrap.min.* is compiled and minified, and bootstrap.*.map files are source maps for browser developer tools.

The partial files matter if you already have a design system and only want the grid or the utilities without the component styles. Sass users skip the compiled files entirely: package.json sets the sass entry to scss/bootstrap.scss and the style entry to dist/css/bootstrap.css, and the exports map exposes ./scss/* so individual partials can be imported.

Only the bundle files carry Floating UI and Vanilla Calendar Pro

Two JavaScript builds ship side by side. The bundled files, bootstrap.bundle.js and the minified bootstrap.bundle.min.js, include Floating UI and Vanilla Calendar Pro. The plain bootstrap.js and bootstrap.min.js are not described as including either one.

The practical cost is that picking the plain file moves the job of providing those two libraries onto you. Floating UI handles the placement of floating elements, and Vanilla Calendar Pro is a date picker library; if a component that depends on either stops working after you switched files, check which build the page is loading before debugging your markup. The repository also keeps a .bundlewatch.config.json and bundlewatch scripts, so bundle size is tracked in its own tooling.

RTL comes from logical properties and one attribute

Every CSS file in the download works for both left to right and right to left layouts, because the styles are written with CSS logical properties. Switching a page to RTL needs only the dir attribute on the html element, for example dir="rtl", with no separate RTL stylesheet to load.

This is a single build for both directions, which simplifies deployment for multilingual sites. The flip side is that any custom CSS you layer on top must also use logical properties, or your own margins and paddings will stay pinned to one side while Bootstrap's components mirror around them.

An ES module package with TypeScript sources and an exports map

On main, package.json declares "type": "module", and the JavaScript source lives in js/src as TypeScript files, with a tsconfig.json at the root. The root export resolves types to ./js/dist/index.d.ts and code to ./js/dist/index.js. Subpath exports cover ./js/src/*, ./js/dist/*, ./dist/js/*, ./dist/css/* and ./scss/*, and there is a mapping that redirects ./js/src/*.js imports to ./js/dist/*.js.

The sideEffects field lists ./js/src/*.ts, ./js/dist/*.js and ./dist/js/*.js. Bundlers read that field when deciding what may be tree shaken, so those modules are marked as not safe to drop. Because the package defines an exports map, deep imports outside the listed subpaths are not part of its public surface; stick to the paths above when importing pieces of Bootstrap.

The docs site is an Astro build that depends on compiled assets

Bootstrap's documentation lives in the repository root, which is why GitHub reports MDX as the primary language. It is built with Astro, searched with Pagefind (configured in pagefind.yml) and hosted on GitHub Pages at getbootstrap.com. Running it locally takes three commands from the root directory:

npm install
npm run test
npm run docs-serve

The middle step is the easy one to skip. npm run test (or a more specific npm script) rebuilds the distributed CSS and JavaScript as well as the docs assets, so jumping straight to docs-serve after a fresh clone means the site is built without that step having run. Once it is up, the site is served at http://localhost:9001. A Node version pin is kept in .nvmrc, so use it rather than whatever Node is on your path. For older versions, the docs are hosted at getbootstrap.com/docs/versions/ and each GitHub release offers its documentation as a download, which is the offline route for v5 users.

Pull requests with JavaScript changes must bring unit tests

Contributors face a firm rule: a pull request that contains JavaScript patches or features must include relevant unit tests under js/tests. HTML and CSS must follow the Code Guide maintained by Mark Otto, and editor settings ship in .editorconfig. Linting is set up through eslint.config.js and stylelint.config.mjs, with spelling checks in .cspell.json and markdown rules in .markdownlint.json.

Bug reports and feature requests go through issue templates, and the issue guidelines ask you to search open and closed issues first. Questions belong in GitHub Discussions, the community Discord or the Bootstrap subreddit rather than the issue tracker. A JavaScript change without tests does not meet the stated contribution rules, so budget for writing them before you open the pull request.

Editorial conclusion

Teams starting a new prototype who are comfortable with prerelease software can install [email protected] and follow the 6.0 docs. Anyone shipping production sites on Bootstrap 5 should not copy the install lines from the main branch; work from the v5-dev branch and the v5.3.x releases (v5.3.8 is dated 2025-08-26) instead. Before adopting either line, confirm which version your package manager resolved, especially through NuGet, whose install command carries no version, and check whether you load bootstrap.bundle.js or the plain build that leaves out Floating UI and Vanilla Calendar Pro.

Frequently asked questions

Official sources

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