PatternFly

@patternfly/patternfly is the core CSS package for PatternFly, the open-source design system originally built by Red Hat for OpenShift, Ansible, and other enterprise console products. It ships pre-compiled, versioned CSS for over 80 components, 8 layouts, and a full utility-class system, along with the Sass source, Handlebars demo templates, and design tokens used to generate them.

Because everything is scoped under a pf-v6- class prefix tied to the package’s major version, teams can adopt PatternFly incrementally or run two major versions side by side during a migration without style collisions. The package includes light, dark, high-contrast, and several theme variants out of the box, driven entirely by swapping design-token stylesheets rather than JavaScript.

What You Get

• Base styles - patternfly-base.css provides reset/normalize, global CSS variables, and typography required for every other PatternFly style to render correctly.
• 80+ component stylesheets - individually scoped SCSS/CSS for accordions, alerts, buttons, cards, forms, modals, tables, and more, each namespaced under a versioned pf-v6-c- class prefix.
• Layout and utility classes - 8 layout primitives (Flex, Grid, Split, Stack, Bullseye, Gallery, Level) and 11 utility groups (spacing, display, text, alignment, box-shadow) for composing pages without custom CSS.
• Design tokens for multiple themes - default, dark, high-contrast, glass, and felt token sets (and their combinations) that can be swapped in to retheme the whole system.
• Icon assets - a bundled PatternFly icon font and SVG icon set generated from the repo’s icon definitions.

Common Use Cases

• Design-system-driven internal tools - engineering teams building admin consoles or internal dashboards import patternfly.css directly for consistent enterprise UI without hand-rolling components.
• Framework binding authors - teams maintaining PatternFly bindings for React or other frameworks depend on this package as the canonical CSS source of truth so styles stay in sync across bindings.
• White-label enterprise products - products like Red Hat’s own OpenShift and Ansible Automation Platform consoles adopt PatternFly’s versioned classes for a cohesive, accessible UI while still overriding design tokens for their own brand.
• Incremental design-system migrations - large codebases running an older PatternFly major version alongside this one during a phased upgrade, relying on the pf-v6- prefix to avoid class collisions.

Under The Hood

Architecture The repo organizes CSS/SCSS source under src/patternfly split into base (reset, normalize, variables, design tokens), components (80 individually scoped SCSS+Handlebars pairs, one directory per component such as Accordion, Alert, and Button, each with its .scss, .hbs demo templates, and an examples/ folder), layouts (8, e.g. Bullseye, Flex, Grid, Split, Stack), utilities (11 groups such as Spacing, Display, Flex, Text), and sass-utilities providing shared mixins/functions/namespacing that enforce the pf-v6-c-/pf-v6-l-/pf-v6-u- class prefixes. gulpfile.mjs (ESM, Gulp 5) orchestrates the build: compiling each component/layout/utility SCSS entry independently, rendering Handlebars demo pages via the sibling @patternfly/documentation-framework package, and generating the PF icon font/SVG set from src/icons definitions. Design tokens live in base/tokens as parallel theme variants (default, dark, high-contrast, glass, felt, and combinations), each a set of SCSS custom-property maps — swapping token files is the mechanism for theming rather than any JS runtime logic. There’s no application code to speak of; the architecture is a token-to-base-to-component/layout/utility layering enforced by naming convention and directory structure, with the sass-utilities namespace files acting as the load-bearing abstraction that keeps all 80+ component class names consistent.

Tech Stack Sass/SCSS is the primary source language, paired with Handlebars templates for component demo markup consumed by the docs framework and a thin JavaScript layer for build scripts and icon-font generation tooling. Build tooling includes Gulp 5, @rspack/core and @rspack/dev-server for the local dev server and docs build, cssnano for CSS minification, stylelint for SCSS linting, ESLint (eslint-config-standard plus React presets) for the small amount of JS, Husky and commitlint for conventional-commit git hooks, BackstopJS for visual-regression screenshot testing, patternfly-a11y (the project’s own accessibility audit CLI wrapping axe-core) for automated a11y checks, and the sibling @patternfly/documentation-framework package to generate the public patternfly.org docs site. The package manager is Yarn 4 (Berry) despite the compiled output publishing to npm, and no runtime dependencies are declared — this is a build-time-only repo whose published artifact is compiled CSS and assets.

Code Quality There are no unit test files or a conventional test directory — testing is entirely visual and behavioral: BackstopJS screenshot-diff regression tests across roughly a dozen theme/mode combinations (dark, glass, high-contrast, felt, and their pairings) catch unintended visual changes, and patternfly-a11y runs full-page WCAG 2.0 AA audits against every component, layout, utility, and demo page. Style is enforced via stylelint for SCSS and ESLint for JS, both wired into lint-staged and Husky pre-commit hooks alongside a commitlint conventional-commit check. CI workflows build a per-PR preview deployment and run semantic-release for automated versioning off conventional commits. Given this is a CSS/asset library rather than application logic, the absence of unit tests is expected; the real quality signal is the breadth of automated visual-regression and accessibility coverage across all 80 components and multiple themes.

API Design PatternFly core’s “API” is a CSS class contract rather than a JS API: consumers import one of a small number of purpose-built entry stylesheets (patternfly-base.css, patternfly.css, patternfly-addons.css, or individual utilities/[Name]/[name].css files) and then apply consistently versioned class names such as pf-v6-c-button or pf-v6-l-flex. The major-version prefix baked into every class name is a deliberate, low-boilerplate way to let consumers run multiple PatternFly major versions side by side during migration without CSS collisions — genuinely useful DX at this scale. Getting started requires no JavaScript wiring beyond an npm install and a stylesheet import, and granular utility-file imports let consumers opt out of loading all 80 components’ CSS if bundle size matters. This isn’t novel in a research sense — it applies established BEM/ITCSS design-system conventions — but the versioned-namespace migration strategy is a deliberate, specific technical choice rather than a generic default.