Bootstrap Component Js

Bootstrap 6 component JavaScript

Every Bootstrap plugin is a TypeScript module in js/src/ that extends BaseComponent, which handles instance registration, config merging, and teardown. Follow the shared structure and a component gets getInstance(), getOrCreateInstance(), data-bs-* config, namespaced events, and dispose() without writing any of it.

The sources are TypeScript, but the runtime patterns are the same ones v5 used with types layered on top. Bootstrap compiles them to JavaScript and emits its own declarations, so consumers need no @types/bootstrap.

For the component's styles, see the bootstrap-component skill.

Workflow

• Step 1: Scaffold the module
• Step 2: Define config options
• Step 3: Implement behavior and events
• Step 4: Wire the data API
• Step 5: Position with Floating UI (optional)
• Step 6: Wrap a third-party library (optional)
• Step 7: Clean up in dispose()
• Step 8: Register and test
• Step 9: Verify

Step 1: Scaffold the module

Create js/src/<name>.ts. Read js/src/alert.ts first — it's the smallest complete example.

/** * -------------------------------------------------------------------------- * Bootstrap widget.ts * Licensed under MIT (https://github.com/twbs/bootstrap/blob/main/LICENSE) * -------------------------------------------------------------------------- */
import BaseComponent from './base-component.js'import EventHandler from './dom/event-handler.js'
/** * Constants */
const NAME = 'widget'const DATA_KEY = 'bs.widget'const EVENT_KEY = `.${DATA_KEY}`const DATA_API_KEY = '.data-api'
const EVENT_SHOW = `show${EVENT_KEY}`const EVENT_SHOWN = `shown${EVENT_KEY}`const EVENT_CLICK_DATA_API = `click${EVENT_KEY}${DATA_API_KEY}`
const CLASS_NAME_SHOW = 'show'const SELECTOR_DATA_TOGGLE = '[data-bs-toggle="widget"]'
/** * Class definition */
class Widget extends BaseComponent {  // Getters  static override get NAME(): string {    return NAME  }}
export default Widget

• NAME is the only required static. BaseComponent derives DATA_KEY (bs.<name>) and EVENT_KEY (.bs.<name>) from it, stores the instance on the element with Data.set(), and disposes any previous instance bound to the same element.
• Keep the section comments (Constants, Class definition, Data API implementation) and member grouping (constructor, // Getters, // Public, // Private, // Static) — every module in js/src/ looks the same.
• Repo style: ES modules only, no semicolons, 2-space indent, single quotes, and override on every member that overrides BaseComponent or Config.
• Relative imports keep the ESM .js extension even though the file on disk is .ts, because tsconfig.json sets moduleResolution: nodenext. Rolldown, Vite, and Vitest all map the specifier back to the .ts source.
• The compiler is strict in ways worth knowing before you write: verbatimModuleSyntax wants type imports marked (import EventHandler, { type BootstrapEvent } from './dom/event-handler.js'), and erasableSyntaxOnly rules out enums, namespaces, and constructor parameter properties.
• Declare instance state as protected declare _foo: Type and assign it in the constructor, the way toast.ts does. declare is type-only; a real field without an initializer would emit _foo = undefined under useDefineForClassFields and wipe whatever the base constructor set.
• v6 has no defineJQueryPlugin and no js/src/util.ts. Helpers live in js/src/util/; DOM wrappers in js/src/dom/ (event-handler, selector-engine, manipulator, data).

Step 2: Define config options

Declare the config shape, the defaults, and the runtime types as module constants, then expose them as statics:

type WidgetConfig = {  animation: boolean  delay: number}
const Default: WidgetConfig = {  animation: true,  delay: 5000}
const DefaultType = {  animation: 'boolean',  delay: 'number'}
class Widget extends BaseComponent {  protected declare _config: WidgetConfig  protected declare _timeout: number | null
  constructor(element?: string | Element | null, config?: Partial<WidgetConfig> | null) {    super(element, config)
    this._timeout = null  }
  // Getters  static override get Default(): WidgetConfig {    return Default  }
  static override get DefaultType(): Record<string, string> {    return DefaultType  }
  static override get NAME(): string {    return NAME  }}
export default Widgetexport type { WidgetConfig }

• The config type does double duty: Default is typed with it, the constructor accepts a Partial<> of it since callers pass a subset, and redeclaring protected declare _config: WidgetConfig narrows BaseComponent's loose config so this._config.delay is a number. DefaultType stays a plain string map — it drives the runtime check, not the compiler. Export the type; the type tests import it.
• Merge order, applied by Config._mergeConfigObj() (last wins): Default → the JSON in data-bs-config → individual data-bs-* attributes → the object passed to the constructor. You don't write any of this.
• data-bs-* names are camelCased when read, so data-bs-auto-hide="false" becomes autoHide: false.
• Every key in DefaultType is validated and throws a TypeError on mismatch. Values are matched as regex, so unions work: 'boolean', '(number|string)', '(string|element|function)'.
• Normalize a value before validation by overriding _configAfterMerge(config) — the usual place to resolve a selector string into an element or coerce a shorthand.

Step 3: Implement behavior and events

class Widget extends BaseComponent {  // Public  show(): void {    const showEvent = EventHandler.trigger(this._element, EVENT_SHOW)
    if (showEvent.defaultPrevented) {      return    }
    this._element.classList.add(CLASS_NAME_SHOW)
    this._queueCallback(() => {      EventHandler.trigger(this._element, EVENT_SHOWN)    }, this._element, this._config.animation)  }}

• Events come in pairs: an infinitive fired before the action (show.bs.widget, cancelable) and a past participle after it (shown.bs.widget). Always bail when the "before" event is defaultPrevented.
• _queueCallback(callback, element, isAnimated) runs the callback after the CSS transition on element finishes, and skips it if the instance was disposed mid-transition. Pass the animation flag from config so non-animated components fire immediately.
• Add a payload when listeners need context: EventHandler.trigger(this._element, EVENT_SHOWN, { relatedTarget }). trigger() returns a BootstrapEvent, an Event widened with the payload keys, so reading them back in a handler needs no cast.
• Query with SelectorEngine (findOne, find, next, prev, getElementFromSelector) instead of raw querySelector, and read or write attributes with Manipulator.
• Bind internal listeners with EventHandler.on(this._element, EVENT_MOUSEOVER, …) using the namespaced constants, so dispose() removes them in one call.

Step 4: Wire the data API

The data API goes at the bottom of the module, after the class, as an import side effect:

/** * Data API implementation */
EventHandler.on(document, EVENT_CLICK_DATA_API, SELECTOR_DATA_TOGGLE, function (event) {  event.preventDefault()  Widget.getOrCreateInstance(this).toggle()})

• Delegate from document and namespace the event with .data-api so it stays distinguishable from user listeners.
• Keep function rather than an arrow when you need the delegated element: EventHandler types the callback's this, so this is the match for SELECTOR_DATA_TOGGLE. Use an arrow and reach for event.target only when you need the actual click target.
• Prefer the shared helpers in js/src/util/component-functions.ts over hand-rolled handlers:
  • enableDismissTrigger(Widget) wires [data-bs-dismiss="widget"] to hide(). Pass a method name for anything else: enableDismissTrigger(Alert, 'close').
  • eventActionOnPlugin(Widget, 'click', SELECTOR_DATA_TOGGLE, 'toggle') handles the "trigger points at one or more targets via data-bs-target" case and skips disabled elements.
• Because these are side effects, the data API only exists once the module is imported. Anything importing a single component file gets that component's data API and nothing else.

Step 5: Position with Floating UI (optional)

Menus, tooltips, and popovers position with @floating-ui/dom, an optional peer dependency. Guard for it in the constructor before calling super() — legal here because the class declares its fields instead of initializing them:

import { autoUpdate, computePosition } from '@floating-ui/dom'
class Widget extends BaseComponent {  protected declare _floatingCleanup: (() => void) | null
  constructor(element?: string | Element | null, config?: Partial<WidgetConfig> | null) {    if (typeof computePosition === 'undefined') {      throw new TypeError('Bootstrap\'s widgets require Floating UI (https://floating-ui.com)')    }
    super(element, config)    this._floatingCleanup = null  }}

Create the positioner when the element is shown and keep the cleanup function so it can be cancelled:

class Widget extends BaseComponent {  // Private  protected _createFloating(): void {    this._updateFloatingPosition()    this._floatingCleanup = autoUpdate(this._element, this._floatingEl, () => this._updateFloatingPosition())  }
  protected _disposeFloating(): void {    if (this._floatingCleanup) {      this._floatingCleanup()      this._floatingCleanup = null    }  }}

js/src/util/floating-ui.ts handles placement so you don't reimplement it: getDefaultPlacement() flips -start / -end for RTL, parseResponsivePlacement() and getResponsivePlacement() support data-bs-placement="bottom-start md:top-end", and createBreakpointListeners() / disposeBreakpointListeners() re-position on breakpoint changes.

Step 6: Wrap a third-party library (optional)

js/src/datepicker.ts wraps vanilla-calendar-pro and is the reference for this pattern:

1. Keep Bootstrap's config surface. Users set data-bs-* options; a private builder (_buildCalendarOptions()) translates them into the library's option shape.
2. Instantiate in a private initializer called from the constructor and hold the instance on a private field typed with the library's own type (protected declare _calendar: Calendar | null).
3. Re-emit the library's callbacks as namespaced Bootstrap events so consumers only learn one API.
4. Call the library's teardown in dispose() before super.dispose(), and null the field.
5. Add the package to peerDependencies in package.json, guard for its absence, and document the extra install step on the component's docs page.

Don't fork or vendor the library, and don't expose its instance as public API — anything users need should be a method or event on the Bootstrap class.

Step 7: Clean up in dispose()

class Widget extends BaseComponent {  // Public  override dispose(): void {    clearTimeout(this._timeout!)    this._observer?.disconnect()    this._disposeFloating()
    super.dispose()  }}

super.dispose() removes the Data entry, removes every listener bound on this._element under EVENT_KEY, and nulls the instance's own properties. Everything else is yours to undo first: timers, MutationObserver / ResizeObserver instances, listeners bound on document or window, Floating UI cleanups, and third-party instances. Leaks here show up as failing "should dispose" specs.

Step 8: Register and test

1. Add the export to js/src/index.ts:

   ts

   export { default as Widget } from './widget.js'

   That barrel is the package entry point and feeds both dist/js/bootstrap.js and the bundle. Nothing else needs updating: Rolldown builds from js/src/index.ts, build/build-plugins.mjs globs js/src/**/*.ts for the per-plugin files in js/dist/, and Vitest picks up js/tests/unit/**/*.spec.js.

2. Extend both type tests. js/tests/types/api.ts asserts the public surface against the sources; js/tests/types/consumer.ts asserts the same surface against the shipped js/dist/*.d.ts, imported through the package name the way a downstream project does. Add the class, its config type, and its methods to both — a declaration-emit bug passes the first and fails the second.

3. Add a spec at js/tests/unit/<name>.spec.js. Specs are plain JavaScript and run in a real Chromium through Vitest browser mode:

   js

   import Widget from '../../src/widget.js'import { clearFixture, getFixture } from '../helpers/fixture.js'
   describe('Widget', () => {  let fixtureEl
     beforeAll(() => {    fixtureEl = getFixture()  })
     afterEach(() => {    clearFixture()  })
     it('should expose the plugin name and data key', () => {    expect(Widget.NAME).toEqual('widget')    expect(Widget.DATA_KEY).toEqual('bs.widget')  })})

   • describe, it, expect, and the hooks are globals (globals: true in js/tests/vitest.config.mts), so don't import them. Import vi from vitest when you need spies or fake timers — that's the preferred API for new specs.
   • js/tests/vitest-setup.js maps the Jasmine API the older specs are written against onto Vitest, so spyOn, jasmine.clock(), toHaveClass, toBeTrue, toBeFalse, and toHaveSize still work. Two gotchas: the shimmed spyOn stubs the method (add .and.callThrough() for the real one), and Vitest 4 dropped the done callback, so an asynchronous test returns a promise and resolves it from the listener.
   • Cover the constructor with both a selector and an element, config coming from data-bs-*, each public method, both events including the cancelable one, the data API without manual instantiation, and dispose(). Coverage counts every file in js/src, so a component with no spec drags the run below the thresholds in js/tests/vitest.config.mts (90% of statements, functions, and lines; 88% of branches) and fails the build.

4. Document it on the component's docs page: add js: optional (or js: required) to the frontmatter, <JsDataAttributes /> in an ### Options section, and <BsTable> tables for options, methods, and events. Demo snippets live in site/src/assets/partials/snippets.js and render with <JsDocs name="live-widget" file="site/src/assets/partials/snippets.js" />.

Step 9: Verify

1. npm run js-lint
2. npm run js-typecheck — tsc --noEmit over js/src and the type tests.
3. npm run js-test-unit, or npm run js-test to add the two Rolldown integration bundles that prove the module is tree-shakeable. Playwright needs its browser once per machine (npx playwright install chromium), and npm run js-debug runs the specs in a visible browser.
4. npm run js — Rolldown compiles the sources to dist/js and js/dist, terser minifies, and tsc emits the .d.ts files. Check the bundle grew by roughly what you'd expect; npm run bundlewatch enforces size budgets.
5. npm start and exercise the component on its docs page, with the keyboard as well as the mouse.

In your own project

package.json maps bootstrap/js/src/*.js to the compiled js/dist/*.js and its declarations, so the same specifier works from JavaScript and TypeScript, and custom components can build on the same base class:

import BaseComponent from 'bootstrap/js/src/base-component.js'import EventHandler from 'bootstrap/js/src/dom/event-handler.js'
class Widget extends BaseComponent {  static override get NAME(): string {    return 'widget'  }}

Two things to keep in mind. Importing a Bootstrap component module runs its data API as a side effect, which is what you want in an app entry point but not inside a library. And DATA_KEY is derived as bs.<name>, so pick a NAME that doesn't collide with a Bootstrap plugin or your instance will replace theirs on shared elements.