# Material UI's older-versions table stops at v6, and the package sits at 9.4.0

> Material UI is a React component library implementing Google's Material Design, MIT licensed and published as @mui/material. Its build and release scripts encode decisions that are invisible from the docs, and its own upgrade table ends three major versions short of the current one.

**mui/material-ui** — Material UI implements Google’s Material Design as a ready-to-use React component library.

- Repository: https://github.com/mui/material-ui
- Website: https://mui.com/material-ui/
- Stars: 99,117 · Forks: 32,511
- Language: JavaScript
- License: MIT
- Published: 2026-08-08 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/mui-material-ui

## Two dist-tags decide what npm hands you: @next and @latest

Material UI is published to npm as @mui/material, and the README spends two lines on the one decision that will bite you: @next points to pre-releases, and @latest is the latest stable release.

```bash
npm install @mui/material
```

Those two lines carry no version constraint beyond the tag, which is the whole problem. Nothing states which pre-release level @next tracks, so a team that installs it once and commits the resulting lockfile is following a moving target until someone pins an exact version. The release history shows how fast the line moves: v9.3.0 was published on 2026-08-05 and v9.3.1 the next day, 2026-08-06, with v9.4.0 following on 2026-08-28. A lockfile that says 9.3.1 is not evidence of neglect, and a lockfile that says 9 is not evidence of pinning. Write the exact version into package.json and let the lockfile record the rest.

## The older-versions table names four frozen doc sites and stops its migration trail at v6

Behind a collapsible Older versions heading, the README keeps hosted documentation for four previous lines: v5.x at v5.mui.com, v4.x at v4.mui.com, v3.x at v3.mui.com and v0.x at v0.mui.com. Each is paired with the upgrade path into the next line: Upgrading from v5 to v6, Upgrading from v4 to v5, Upgrading from v3 to v4, and Upgrading to v1 from the v0.x era.

Read that against the version field in package.json, which is 9.4.0, and the gap is the useful part. The four guides cover v0 to v6. A team still on v4 who follows this table arrives at the v4 to v5 guide, then the v5 to v6 guide, and then has three more major hops with no link offered here. Meanwhile the four frozen doc sites are exactly the URLs older tutorials and search results point at, so a reader following a link from a three-year-old article lands on documentation for a version you are not running.

Treat the version table as an index rather than a route. Check the changelog for your target version before you plan the migration, because that is where the per-release detail lives.

## build:public runs lerna with --no-private, so an unmarked package never ships

The root manifest is @mui/monorepo, marked private, version 9.4.0, and it refuses a non-pnpm install outright: the preinstall script is npx only-allow@1.2.2 pnpm, pinned to an exact version of the guard rather than a range. Alongside pnpm-workspace.yaml and pnpm-lock.yaml sit lerna.json and nx.json, so the workspace is a pnpm install driven by two task runners.

Two build scripts matter, and they differ by one flag:

```bash
lerna run --no-private build
```

That is the whole of build:public. The plain build script is lerna run build --ignore docs, which runs every package's build and skips the documentation. The public variant adds --no-private, so it builds only the packages not marked private.

Read that as a default and you get the failure mode. What decides whether a package reaches a registry is the absence of a private flag, not the presence of a public one. Add a workspace package, forget to flip it, and the build still passes, the test run still passes, and the package is simply not in the set that gets published.

## lerna bumps the version, code-infra writes the tag

Publishing is two tools in sequence, and the split is visible in the flags:

```bash
lerna version --no-changelog --no-push --no-git-tag-version --no-private --force-publish=@mui/core-downloads-tracker
```

The version step explicitly declines to write a changelog, to push, and to create a git tag. So lerna computes and writes version numbers and stops there. The tag and the GitHub release come from a different command, code-infra publish --github-release, which has a dry-run twin at release:publish:dry-run.

Two consequences for anyone tracking releases. If the second step fails, you are left with bumped versions in the working tree, no tag and no release, and the changelog is not lerna's job either: that comes from node scripts/releaseChangelog.mjs. And the force-publish argument names one internal package, @mui/core-downloads-tracker, which therefore gets a version bump on every release even when nothing in it changed. Expect that package to move more often than the component packages, and do not read its version as a signal of anything.

## examples/ is the only complete list of the integrations kept working

The README points at a collection of example projects, and the directory is the most honest answer to the question does it work with my setup. It holds sixteen, including material-ui-via-cdn, material-ui-vite, material-ui-vite-ts, material-ui-vite-tailwind-ts, material-ui-pigment-css-vite-ts, material-ui-pigment-css-nextjs-ts, material-ui-nextjs-ts, material-ui-nextjs-pages-router-ts, material-ui-react-router-ts, material-ui-remix-ts, material-ui-gatsby, material-ui-express-ssr and material-ui-preact.

Three things in that list change the picture. A Tailwind setup has a maintained example, and so does Pigment CSS, so the styling story is not one decision. A Preact example means the supported surface is wider than React with a bundler. And material-ui-via-cdn is the one path with no build step at all, the cheapest way to see whether the components suit you before touching a toolchain.

The trap is that material-ui-nextjs-ts-v4-v5-migration sits in the same directory as the current starters. It is a migration, not a template, and copying the wrong folder is easy when you are working from a directory listing. Each example is a snapshot with its own dependency set, and the README does not say which versions they pin, so treat them as reference code and let your installed package version decide your numbers.

## How-to questions are routed to Stack Overflow, not to the issue tracker

The Questions section of the README is one sentence with real consequences: for how-to questions that don't involve making changes to the code base, please use Stack Overflow instead of GitHub issues.

So the routing is explicit. How do I theme this one component is a Stack Overflow question. A reproducible defect is a GitHub issue. A proposed improvement belongs in the contribution process described in CONTRIBUTING.md, which is also where the README says to learn how to build and test your changes. Security problems take a third route again, through the security policy, which covers the supported versions and the contact information for reporting an issue.

What this changes in practice is where you look for an answer. A question about configuring a component for your own application is one the maintainers have redirected away from the tracker, so the answer has to come from the documentation or from someone else's write-up. The badge row also links a specific long-running issue, number 27062, and an external tracker for the average time to resolve an issue, which tells you someone is watching that number. It is a measurement, not a response guarantee.

## MIT covers this repository, not MUI X or the store templates

The licence section is one line: this project is licensed under the terms of the MIT license, pointing at the LICENSE file at the root. What sits outside that grant is named elsewhere in the same README.

Core functionality is extended by MUI X, described as a suite of complex components for advanced use cases, and it lives in its own repository. Complete templates and themes are in the MUI Store. The MIT text here covers the code in this repository, and a team that reads MIT as covering the whole product will find the advanced data components and the polished templates addressed somewhere else. That is a reading of where the licence text sits, not a licensing opinion.

Funding follows the same split. Sponsorship is described in two tiers, Diamond at $1,500 a month or more and Gold at $500 a month or more, the latter collected through Open Collective or Patreon. Infrastructure is credited to three services: GitHub hosts the repository and coordinates contributions, Netlify distributes the documentation, and CodeCov monitors test coverage. A Tidelift configuration sits at the root as well, which is how the project routes commercial support requests.

## Two changelog files and an a11y check with no published score

Maintenance signals here are current and specific. The last push to master was on 2026-09-29, and the three most recent releases are v9.4.0 on 2026-08-28, v9.3.1 on 2026-08-06 and v9.3.0 on 2026-08-05. The repository is not archived and the default branch is master.

Two details decide how much work an upgrade costs you. The changelog is split across CHANGELOG.md and CHANGELOG.old.md at the root, so finding when a behaviour changed means knowing which of the two files holds your version, and the README says only that the changelog is regularly updated. And accessibility has a script of its own, a11y:scorecard, with a check form, a11y:scorecard:check, that takes the --check argument for use in a gate. The score it produces is not published in the README, so a team that wants a number has to run the script rather than read one off the page.

For test running, vitest.config.mts and vitest.shared.mts sit at the root next to a test/ directory, and docs prose is linted separately through a remark configuration and a Vale configuration. Documentation text is checked by tooling here, which is worth knowing before you open a pull request that changes a paragraph.

## Conclusion

Adopt @mui/material if your application already has a React build and you want Material Design components without writing them. Two things to check before you commit. First, the dist-tag: the README says @next points to pre-releases and @latest is the stable line, so pin an exact version in your lockfile rather than tracking a tag. Second, your upgrade path: the four guides the README links cover v0 to v6 while package.json reports 9.4.0, so a team several majors behind has to find the intervening guides outside this page. Contributors should also read the build scripts, because whether a package ships is decided by the absence of a private flag in build:public.

## FAQ

### how to install material ui

The package is published to npm as @mui/material. The README states that @next points to pre-releases and that @latest is the latest stable release, so the tag you choose is what decides whether you install a pre-release.

### What is material UI vs Bootstrap?

Material UI is a React component library carrying an independent implementation of Google's Material Design system, MIT licensed in this repository. The README does not compare it with Bootstrap; the nearest boundary it draws is that complex component cases are left to MUI X.

### Is Material UI free or paid?

This project is licensed under the terms of the MIT license. The README separately points to complete templates and themes in the MUI Store and to MUI X for complex components, so the MIT grant covers the library in this repository rather than everything published under the product name.

### how to use material ui in react

The README sends you to the Material UI documentation to get started and to a collection of example projects. The examples directory includes material-ui-vite-ts, material-ui-nextjs-ts, material-ui-remix-ts and material-ui-via-cdn, which is the shortest route to a working setup.

### Is material UI better than Tailwind?

The repository does not make that comparison. What it does provide is material-ui-vite-tailwind-ts in the examples directory, alongside material-ui-pigment-css-vite-ts, so a Tailwind setup is a configuration the project keeps a maintained example for.

## Sources

- [Official documentation](https://mui.com/material-ui/)
- [Official README](https://github.com/mui/material-ui#readme)
- [Project repository](https://github.com/mui/material-ui)
- [Release notes](https://github.com/mui/material-ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mui-material-ui