# Primer ViewComponents: the Rails design system in maintenance mode

> Primer ViewComponents is GitHub's Ruby implementation of the Primer design system, shipping server rendered components for Rails applications. It has been in maintenance mode since February 2026 while GitHub moves its own interfaces to React, so the interesting question for a new adopter is not what the components do but whether depending on them is still a sound plan.

**primer/view_components** — ViewComponents for the Primer Design System

- Repository: https://github.com/primer/view_components
- Website: https://primer.style/components/
- Stars: 583 · Forks: 144
- Language: Ruby
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/primer-view-components

## Maintenance mode, stated plainly at the top of the README

The first thing in this README is a warning block, and it is the single most important fact about the project.

As part of GitHub's move to React-based interfaces, Primer ViewComponents is in maintenance mode as of February 2026. Maintenance mode means the project is not accepting new features, components or significant enhancements. The Primer team at GitHub will continue providing security updates, dependency bumps and critical or P0 bug fixes. Issues, pull requests and discussions remain open, but maintainer response is not guaranteed.

The reason given is a strategic one. The Primer team continues to focus its resources on strategic investments that help GitHub and its customers be successful, while making developers' lives easier. The Primer design system itself remains part of that vision through guidance, tooling, and ready-to-use React and web components.

Then the two instructions that matter for an outside adopter, and they are different. Internal GitHub consumers are encouraged to plan to migrate from Primer ViewComponents to Primer React. Non-GitHub consumers should consider forking and maintaining a copy of this repository.

That is a candid statement of the situation. A fork is a real maintenance commitment: you inherit the test suite, the build and the security response for a library whose upstream will only push critical fixes. The README also points to a discussion thread for the maintenance mode announcement where questions can be posted.

The project is MIT licensed, the last push was on 2026-10-14, and the recent releases are v0.53.5 on 2026-09-11, v0.53.4 on 2026-09-02 and v0.53.3 on 2026-08-25. Those releases are the dependency bumps and fixes continuing in the background.

## What the gem actually is: server rendered Primer components for Rails

Primer ViewComponents is ViewComponents for the Primer Design System, and the repository is a Ruby gem that also publishes a JavaScript package.

The Ruby side is the one most people mean. It is a collection of ViewComponent classes implementing the Primer component set, so a Rails application renders Primer markup, styles and behaviour through ordinary Ruby view code rather than through a JavaScript widget.

The documentation lives at primer.style/components, and the README's own note is worth reading twice. The library is under active pre-1.0 development, and breaking changes are likely in patch releases.

That sentence does a lot of work. A version number of 0.53.x with a note that patch releases can break you means semver is not protecting you, and the changesets setup in the repository is consistent with that, since changesets is the tool that drives conventional version bumps across a monorepo of packages.

The JavaScript side exists so that the components can be exercised outside a Rails process, and the package.json describes it as @primer/view-components with a version matching the gem at 0.53.5. The exports map shows how the two formats are exposed, with a root export that points at the ES module for import and the compiled asset for require, a separate classnames export with its own ESM and CommonJS builds, and a wildcard for the app directory:

```json
  "exports": {
    ".": {
      "types": "./app/components/primer/primer.d.ts",
      "import": "./app/components/primer/primer.js",
      "require": "./app/assets/javascripts/primer_view_components.js"
    },
    "./classnames": {
      "types": "./static/classnames.d.ts",
      "import": "./static/classnames.js",
      "require": "./static/classnames.cjs"
    },
    "./app/*": {
      "types": "./app/*.d.ts",
      "default": "./app/*"
    },
    "./*": "./*"
  },
```

The wildcard export at the end is the interesting one, since it means consumers can reach into individual component files rather than only the barrel. That is the escape hatch a large project needs, and it also means the set of files you depend on is not fixed by the package alone.

## A repository that is really a dozen projects at once

The top level listing is long, and it is worth reading as a map of what this repository actually has to maintain.

The Ruby gem side is the familiar Rails shape: a primer_view_components.gemspec, a Gemfile and Gemfile.lock, a Rakefile, a lib directory, an app directory holding the components and their assets, a config directory, a test directory, a Procfile and a Procfile.test for running the app, and a demo directory that is a full application with its own Gemfile, config.ru, Rakefile, kuby.rb and a vite.config.mts.

Alongside that there is a full front end toolchain. There is a package.json, a rollup.config.js, a postcss.config.js, an eslint.config.mjs and a tsconfig.json, plus a playwright.config.ts and a .playwright directory, so the components are tested in a real browser rather than only in Ruby. There is a .stylelintrc.json for the styles, a .rubocop.yml for the Ruby, a .erb_lint.yml with an .erb_linters directory for the templates, a .markdownlint-cli2.cjs for the documentation, and a .simplecov for coverage. A .devcontainer and a .copilot directory round out the developer tooling.

The documentation and preview directories are also substantial. There is a docs directory, a previews directory, a static directory for the shipped assets, a script directory and a templates directory. The templates directory is what the generators use, and there are three Thor generators at the root: component_generator.thor, component_status_migrator.thor and linter_generator.thor.

Those generators are worth a second look, because they show what the project considered part of its job. A component generator scaffolds a new component. A status migrator handles the status field of components, presumably a deprecation or lifecycle attribute. A linter generator produces the lint configuration, which is how a project keeps hundreds of components consistent with the same rules without anyone maintaining the rules by hand.

For someone considering a fork, that list is the maintenance surface. A component library with a demo app, a browser test suite, a style linter, a Ruby linter, a template linter, three generators and a documentation site is a substantial thing to own.

## The build and lint pipeline, as the scripts describe it

The npm scripts in package.json give an accurate picture of how the two ecosystems meet.

The prepare script runs script/build-assets, which is the step that compiles the Ruby-side assets into the JavaScript that the package ships. The clean script is git clean -fdX -- app/, removing ignored files under the app directory, which tells you the compiled output lives there and is not tracked.

Linting is split by language and chained. The lint script runs lint:stylelint and then lint:eslint, and lint:stylelint is stylelint with the --rd and -q flags over the component stylesheet glob, with a matching fix variant. The styles use a .pcss extension rather than plain CSS, and the stylelint configuration file is a .stylelintrc.json, so the components are authored in a preprocessed CSS dialect and the pipeline has to handle both the preprocessing and the linting of the result.

The gem is published as open source under the terms of the MIT License, and the repository carries a LICENSE.txt, a CHANGELOG.md, a CODE_OF_CONDUCT.md and a CONTRIBUTING.md. There is also a .changeset directory, which is the versioning tool's configuration and confirms that releases are cut from changesets rather than by hand.

One detail in the package.json worth noting for anyone integrating the JavaScript build: the published files list is narrow and deliberate. It includes the static JSON and the classnames builds, the compiled JavaScript under app/assets, the component JavaScript, CSS and CSS JSON under app/components/primer, and the form helpers under app/lib/primer/forms. Everything else in the repository, including the Ruby source, the tests and the documentation site, is not part of the npm package.

## What to do if you are in the market for a Primer implementation now

The README gives a direct answer, and it is worth taking it at face value rather than looking for a workaround.

If you are inside GitHub, the instruction is to plan a migration to Primer React. The Primer design system survives that move in its React and web component forms, and the guidance and tooling links point there, with the design system documentation at primer.style/product/ui-patterns, the getting started tooling page, the React components and the github-elements repository for web components.

If you are outside GitHub, the instruction is to consider forking and maintaining a copy of this repository. That is a deliberate recommendation rather than a shrug, and it comes with a cost that the fork decision has to absorb: the upstream will keep making critical fixes, so your fork has to decide whether to track those releases or diverge.

The realistic options for a new project, then, are the React implementation, the web components, or a fork of this one. Only the third keeps the server rendered Rails model, and only the first two are actively developed. That is the actual decision this repository is now about, and it is not a decision the component catalogue can influence any more.

For an existing Rails application that already uses these components, the situation is different. The critical fixes and dependency bumps will keep arriving, the migration path to Primer React is a project in itself, and the library is stable enough in practice that continuing to use it while you plan the migration is a reasonable position. That is the case the maintenance mode policy is written for.

One caution applies to any of these paths. The library is under active pre-1.0 development with breaking changes likely in patch releases, so a version bump in the middle of a sprint can change a component's markup or API. If you adopt it, pin the version and read the CHANGELOG.md before each bump rather than letting a lockfile update move under you.

## Conclusion

Adopt Primer ViewComponents only if you are maintaining an existing Rails application that already uses it and you want the remaining security updates and dependency bumps rather than a migration. Do not start a new Rails project on it, because the project is not accepting new features, components or significant enhancements and the README itself tells non-GitHub consumers to consider forking and maintaining a copy. Before you commit, read the maintenance mode announcement in the discussions, check the CHANGELOG.md for the current version, and note that the library is under active pre-1.0 development, so breaking changes are likely in patch releases.

## FAQ

### What is the status of Primer ViewComponents?

It has been in maintenance mode since February 2026, as part of GitHub's move to React-based interfaces. It is not accepting new features, components or significant enhancements, but the Primer team will continue providing security updates, dependency bumps and critical or P0 bug fixes, and issues and discussions remain open with maintainer response not guaranteed.

### What should a non-GitHub developer do with Primer ViewComponents?

The README says non-GitHub consumers should consider forking and maintaining a copy of the repository, while internal GitHub consumers are encouraged to plan to migrate to Primer React. Questions can be posted in the maintenance mode announcement discussion.

### Is Primer ViewComponents safe to depend on for a new Rails project?

The README notes the library is under active pre-1.0 development and that breaking changes are likely in patch releases, and the project is no longer taking new components. For a new project the active paths are Primer React and the web components in github-elements.

### What does the Primer ViewComponents package ship to npm?

The package is @primer/view-components, version 0.53.5, and the published files are the static JSON, the classnames builds, the compiled assets under app/assets, the component JavaScript, CSS and CSS JSON under app/components/primer, and the form helpers under app/lib/primer/forms.

### What tooling does the Primer ViewComponents repository use?

The npm scripts run a prepare step of script/build-assets, chain stylelint over the component pcss files with eslint, and there are separate configurations for rubocop, erb lint, markdownlint, stylelint and Playwright for browser tests, plus a .changeset directory for versioned releases.

## Sources

- [License: MIT](https://github.com/primer/view_components/blob/main/LICENSE)
- [primer/view_components on GitHub](https://github.com/primer/view_components)
- [Project website](https://primer.style/components/)
- [README](https://github.com/primer/view_components/blob/main/README.md)
- [Releases](https://github.com/primer/view_components/releases)

---

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