Base Web's engagement notice, its @next install tag, and the tsc call that cannot fail the build

The README opens with a notice that engagement is limited

The first thing the README does is warn you, and the wording is deliberate. The maintenance status line states that engagement with this repository is being limited while internal development continues to be mirrored, and it links to a post on Open Source Engagement and Future for the details. That distinction matters more than the usual release cadence question, because a mirror is not the same thing as a project taking outside work. Code still arrives, since the pushes continue, but the notice describes the arrival as a mirror of what Uber does internally rather than as a response to the public issue queue. The README then gives a different route for the one group that can still file issues: Uber developers are pointed at a separate issue link and a separate contribute link. For an outside reader, that pairing is the whole story about where a bug report goes and who reads it.

The npm version and the GitHub release tags disagree by five majors

Two versioning records sit in the project and they do not line up. The published package declares its version in package.json, where it reads 18.2.0. The release tags tell a different story: the most recent are v13.0.0, dated 2023-06-13, before it v12.2.0 from 2022 and v12.1.3 before that. So the version you install from npm is five major versions ahead of the newest tag visible in the release history, and the tags stopped moving years before the package version arrived where it is. Nothing in the README explains the gap, and a PUBLISHING.md sits in the repository root without being referenced from the usage section. The practical consequence is that you should not read a GitHub tag as a proxy for what npm currently serves. If you want to know what a given major contains, the tag list will not tell you, and the package's own metadata is the record to check.

The install command points at the @next tag, not at a version

Both documented install commands request the same floating tag rather than a release:

# using pnpm
pnpm add baseui@next styletron-react styletron-engine-monolithic

# using npm
npm install baseui@next styletron-react styletron-engine-monolithic

That is the instruction as written, and for a component library it is an unusual default. A tag rather than a range means the resolved contents can change between two installs of the same manifest, so a lockfile is what actually holds your build still. It also sits oddly beside the maintenance notice, because the notice describes the repository as mirroring internal development, and @next is where mirroring work would surface first. The package name is `baseui`, which differs from the repository name `baseweb` and from the site name Base Web, so a search for one does not reliably surface the other.

Two peer packages have to be installed by name, alongside the library

The library does not install on its own. The commands add `baseui` together with `styletron-react` and `styletron-engine-monolithic`, and the styling engine is wired up in application code rather than configured inside the component tree. The documented setup constructs a Styletron engine and passes it down through a provider before any component renders:

import { Client as Styletron } from "styletron-engine-monolithic";
import { Provider as StyletronProvider } from "styletron-react";
import { LightTheme, BaseProvider, styled } from "baseui";
import { StatefulInput } from "baseui/input";

const engine = new Styletron();

The provider nesting is fixed: the styling provider wraps the design system's BaseProvider, which carries a theme, and only inside that do components appear. Note also that the engine is constructed with no arguments in the example. The pair is separate from the library, and both Base Web and Styletron ship their own TypeScript definitions.

The declaration build ends in a clause that discards its own failures

Look at the library's type declaration script in package.json and the last part of it is `|| true`:

tsc -p tsconfig.dist.json || true

In a shell, that clause makes the command succeed no matter what tsc reports. The declaration build is configured through its own tsconfig file, tsconfig.dist.json, separate from the tsconfig.json at the repository root, so the intent is clearly to emit declarations for the published package rather than for development. The effect of the trailing clause is that a type error during that step does not stop a build. A consumer installing from a registry sees whatever declarations were produced, with no signal from the package build that the step failed. The repository also carries a .lintstagedrc and a .husky directory, neither of which the usage section mentions.

The publish step filters five kinds of files out of the tarball

The library build is a babel invocation over src, and its ignore list is part of what you receive. The script targets .ts, .tsx, and .js extensions, writes to dist using a babel config kept in the publish directory rather than at the root, and filters out test files, files under __tests__, anything named e2e, the template-component directory, and anything under test. Two consequences for a consumer. First, the component templates are excluded on purpose, so the template is not shipped as part of the package. Second, the e2e pattern is excluded too, which means end-to-end coverage is a repository concern rather than something you inherit on install. The build system is Babel-based with a separate declaration pass, so the published output is compiled rather than the raw source, and the package is marked sideEffects-free in its metadata.

The dependency list carries two date libraries and pins three packages exactly

The dependency block is broad, and a few entries are worth reading before you install. Two full date libraries are present at once: moment at ^2.29.4 and date-fns at ^2.28.0, and alongside them two adapter packages, @date-io/moment and @date-io/date-fns, each at ^2.13.1. A date component that supports both backends carries both libraries, so the dependency weight is a design decision baked into the package rather than something a consumer opts into. At least seven entries are pinned to exact versions instead of ranges: csstype at 2.6.11, just-extend at 4.1.1, memoize-one at 5.0.0, mockdate at 2.0.5, react-dropzone at 9.0.0, react-map-gl at 5.2.13 and react-uid at 2.3.0. Pinned transitive style entries mean you get exactly those builds until something above them moves. A consumer on React 18 should also note react-is is declared at ^17.0.2, and the peer set has to be satisfied before any of this resolves.

The repository root carries two lockfiles for two package managers

Both pnpm-lock.yaml and package-lock.json sit at the top level of the tree, alongside the packages, publish, and documentation-site directories. That matches the install instructions, which show a pnpm form and an npm form for the same three packages. A repository with two lockfiles is not a contradiction in practice as long as one is authoritative, but nothing in the README names which one is, and the scripts do not settle it either: the library build, the docs build, and the ladle build are all plain script names that a contributor could run with either manager. Two related details sit nearby. The prepare script runs husky install, so hooks are set up as part of installing, and the pre-commit configuration is a .lintstagedrc at the root. The documentation site is a Next application under documentation-site, built with next build, while component examples are served by ladle from the .ladle directory.

Editorial conclusion

Base Web is a reasonable choice for a team already committed to the Base design language, and a poor one for anyone who needs an actively triaged upstream. Before adopting it, read the engagement notice rather than the component count, and pin an exact version rather than following @next, since the tag tracks a stream the project describes as a mirror of internal work. If you are at Uber, the README points you at internal issue and contribution routes instead of the public tracker.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. uber/baseweb on GitHub