CoreUI

CoreUI is an open-source front-end framework built on top of Bootstrap 5 that ships as a compatible drop-in replacement with expanded component coverage — accordions, avatars, callouts, chips, sidebars, headers, footers, and more — compiled to the same CSS/JS bundle format teams already use with Bootstrap. Every interactive widget (Dropdown, Modal, Tooltip, Collapse, Sidebar, Chip, and others) extends a shared BaseComponent class that handles config merging, per-element instance storage, and namespaced event dispatch, so new components behave consistently with the ones Bootstrap already ships.

Beyond the CSS/JS core, CoreUI’s ecosystem includes framework-native bindings for React, Vue, and Angular, plus a documentation site built with Astro. Its main differentiators over stock Bootstrap are CSS logical properties for automatic RTL/LTR layout support (no separately maintained .rtl.css variant needed) and a move to Dart Sass Modules (@use/@forward) ahead of Bootstrap’s own migration off legacy @import.

What You Get

• A full Bootstrap 5-compatible CSS and JS bundle, with logical-properties-based RTL/LTR support built in
• Additional components beyond stock Bootstrap: avatars, callouts, chips/chip-sets, sidebars, headers, and footers
• A shared BaseComponent JS class giving every widget consistent instance data, event namespacing, and config handling
• Framework-native bindings for React, Vue, and Angular for component-driven admin UI development
• A documentation and demo site built with Astro, covering every component with live examples

Common Use Cases

• Building an admin dashboard UI on Bootstrap-compatible markup without hand-rolling extra components
• Migrating an existing Bootstrap 5 project to pick up additional components (avatars, chips, sidebars) without a rewrite
• Building multilingual apps that need native RTL/LTR layout support via CSS logical properties instead of a separate stylesheet
• Standing up a design system quickly on top of CoreUI’s Sass Modules and utility classes

Under The Hood

Architecture CoreUI’s JavaScript layer centers on a single BaseComponent class (js/src/base-component.js) that every widget — Dropdown, Modal, Tooltip, Collapse, Alert, Carousel, Offcanvas, Popover, Scrollspy, Sidebar, Tab, Toast, Chip, ChipSet, ChipInput — extends. BaseComponent itself extends a Config base class, so construction always follows the same path: resolve the target element via getElement, merge instance/data-attribute config through _getConfig/_mergeConfigObj/_configAfterMerge, then register the instance in a per-element Data map (js/src/dom/data.js) keyed by a DATA_KEY static so getInstance/getOrCreateInstance can retrieve the same widget instance later. DOM interaction is centralized through dom/event-handler.js (namespaced, delegated events), dom/manipulator.js, and dom/selector-engine.js, and stateful cross-cutting concerns (backdrops, focus trapping, scrollbar compensation, swipe gestures, tooltip/popover templating) live as separate util classes composed into individual widgets rather than duplicated per component. Two parallel build targets (js/index.esm.js, js/index.umd.js) expose the same source tree for ESM and UMD consumers, while CSS is an independently versioned Sass pipeline (scss/) using Dart Sass’s module system, with legacy .import.scss shims kept alongside each partial for consumers still on @import. Changing BaseComponent’s config/data-key contract would ripple through every widget file, since none reimplement that lifecycle independently.

Tech Stack The JS core has no runtime dependencies beyond an optional peer dependency on @popperjs/core ^2.11.8 for dropdown/tooltip/popover positioning; everything else is vanilla ES modules. The build pipeline compiles CSS with Dart sass, autoprefixes via postcss, and minifies with cleancss; JS is bundled with rollup and minified with terser, producing standalone and jQuery-compatible (defineJQueryPlugin) bundle variants. Linting runs eslint (flat config, eslint.config.mjs) for JS and stylelint for Sass/CSS, both wired into CI (css.yml, js.yml, lint.yml) alongside a CodeQL security scan. The documentation site (docs/) is a separate Astro project using @astrojs/mdx and a companion @coreui/astro-docs package, built and HTML-validated (vnu-jar) as its own CI job. TypeScript is present only as a devDependency for tooling, not as the library’s own source language.

Code Quality Unit tests live under js/tests/unit/ (33 spec files covering essentially every widget — dropdown.spec.js, modal.spec.js, sidebar.spec.js, chip-set.spec.js, plus a dedicated jquery.spec.js for the jQuery plugin path) and run under vitest, with a separate jQuery-flagged test run and integration bundle tests built via dedicated Rollup configs. Naming is consistent across widgets (NAME, DATA_KEY, EVENT_KEY, EVENT_* constants), and each source file carries a standard header attributing its Bootstrap origin and MIT license. There’s no static type system over the JS source — no TypeScript, no enforced JSDoc types — so type safety relies entirely on test coverage and code review. CSS quality is enforced by stylelint plus an unused-Sass-variable check (fusv), and lockfile integrity is checked via lockfile-lint, all run in CI on every push.

API Design CoreUI’s public API deliberately mirrors Bootstrap’s own — the same data-coreui-* attribute triggers, the same static getInstance/getOrCreateInstance retrieval pattern, and the same namespaced event convention — so a team already fluent in Bootstrap’s JS plugins can adopt CoreUI’s extra widgets (Chip, ChipSet, ChipInput, Sidebar) with no new mental model. Its main developer-experience differentiator over stock Bootstrap is CSS logical properties for automatic RTL/LTR support and Sass Modules (@use/@forward) as the primary authoring format rather than legacy @import. Getting started is a single package install (npm install @coreui/coreui) plus a CSS/JS include, matching Bootstrap’s own onboarding path — the tradeoff is that CoreUI extends and modernizes an existing interaction model rather than introducing a new one.