Remove hard dependency on Extension:Bootstrap

[malberts]

Of the Bootstrap skins listed on https://www.mediawiki.org/wiki/Category:Skins_based_on_Bootstrap, only Chameleon depends on the Bootstrap extension. All other skins bundle their own resources. By requiring that extension, the wiki ends up loading all resources twice, and some skins run into JS event issues as mentioned in #93.

For non-Bootstrap skins that still want to use BootstrapComponents, the extension would still be required.

The check for Bootstrap availability should therefore be:

• if one of the listed skins, excluding Chameleon, is enabled
• else if Extension:Bootstrap is enabled (the right version, since the extension no longer enforces it, maybe via composer "suggest"?)
• fail with current error

[malberts]

Summary and revised direction

Working through this, the conclusion came out different from the title: rather than removing the Extension:Bootstrap dependency, keep it required and fix the actual harm it causes, which is Bootstrap being loaded twice.

The real problem

BootstrapComponents hard-requires Extension:Bootstrap (the composer require, plus the die() gate in the init callback) and then loads ext.bootstrap.styles / ext.bootstrap.scripts unconditionally on every page, in onParserAfterParse, with a comment saying it is loaded always. That double-loads Bootstrap on any skin that already loads it, and that turns out to include Chameleon:

• Skins that bundle their own Bootstrap (Medik, Tweeki): the skin's Bootstrap plus Extension:Bootstrap's, so two different Bootstrap builds on one page.
• Chameleon: it registers a renamed clone of the module, zzz.ext.bootstrap.styles (the zzz. prefix is a load-order device so Bootstrap sorts last), and declares that in its skin styles. Because the module name differs from ext.bootstrap.styles, ResourceLoader cannot dedupe the two, so a Chameleon page requests the same Bootstrap CSS twice:

load.php?...modules=ext.bootstrap.styles&only=styles&skin=chameleon
load.php?...modules=zzz.ext.bootstrap.styles&only=styles&skin=chameleon

Confirmed on a live Chameleon plus BootstrapComponents install. The scripts do dedupe, because Chameleon and BootstrapComponents both add ext.bootstrap.scripts under the same name; it is specifically the styles that double.

So the "loading all resources twice" and the JavaScript event issues from #93 that this issue describes are a current defect, and they affect Chameleon as well as the self-bundling skins.

The change

Move the ext.bootstrap.* loading out of the parse phase, where it is baked into the skin-agnostic parser cache, into an output-phase hook where the active skin is known, and skip it when the active skin already loads Bootstrap itself. BootstrapComponents keeps an internal list of those skins (Chameleon, Medik, Tweeki). Skipping is safe for each: Chameleon still loads Bootstrap through its clone, and the self-bundling skins ship their own. Skins that do not load Bootstrap (Vector, Timeless, and so on) keep getting ext.bootstrap.* from BootstrapComponents.

Nothing else changes: no composer change, no change to the init gate, and no change to SetupAfterCache / addAllBootstrapModules(). That call only configures which Bootstrap modules Extension:Bootstrap compiles into ext.bootstrap.styles; it does not put anything on a page, so it is harmless either way.

Why keep the require rather than move to suggest

• Composer keeps enforcing the version. BootstrapComponents 6.x targets Bootstrap 5, so it needs Extension:Bootstrap ^6.0 (Bootstrap 5.3), and it must reject a future Extension:Bootstrap 7 that moves to Bootstrap 6. Composer expresses exactly that today. Moving to suggest would push the check into runtime code, and since Extension:Bootstrap does not expose its bundled Bootstrap library version, that check could only be a proxy on the extension version.
• Extension:Bootstrap stays a guaranteed Bootstrap 5 floor, which makes not-skipping the safe default: a page that loads Extension:Bootstrap's Bootstrap is always correct, so skipping becomes a pure optimization rather than a load-bearing correctness decision.
• The only thing suggest would buy is installing without Extension:Bootstrap, which is worth little: wikis running Chameleon have it regardless, and on a skin-only wiki it is just an unused extension in the tree.

Why an internal list rather than a configuration variable

Whether a skin loads its own Bootstrap is a fact about the skin, the same on every wiki, not a per-wiki policy, so there is no legitimate reason for two wikis to answer it differently for the same skin. A variable also could not recover a version mismatch: a Bootstrap 4 skin on BootstrapComponents 6.x is broken whether or not it is listed, because the skin loads its own Bootstrap regardless. If a Bootstrap 5 skin turns up that the list does not know, that is a one-line addition, and it double-loads safely until then. An override variable can always be added later if a real need appears.

Known limitations to document

• Version-matching is the operator's responsibility for self-bundling skins. BootstrapComponents 6.x is the Bootstrap 5 extension, so a Bootstrap 4 skin (an older Medik or Tweeki) means BootstrapComponents 5.x. Nothing enforces this, because self-bundling skins declare no Extension:Bootstrap dependency for composer to see. Chameleon is the exception: it declares its own Extension:Bootstrap dependency, so composer transitively keeps it and BootstrapComponents in step, and Chameleon 5.x will not install alongside BootstrapComponents 6.x.
• The provided Bootstrap's exact version is not verifiable. BootstrapComponents cannot introspect a skin's bundled Bootstrap, so it targets Bootstrap 5.3 and assumes Bootstrap 5 compatibility (text-bg-*, for instance, needs Bootstrap 5.2 or later). A genuine mismatch is a bug report rather than something BootstrapComponents can detect.

_{AI-authored — Claude Code, Opus 4.8; design iterated with @malberts, who redirected the approach twice and corrected two factual errors of mine; reviewed by him before posting; the Chameleon double-load was verified on a live Chameleon plus BootstrapComponents install, the rest is from reading the source.}

[malberts]

Where the Bootstrap duplication stands after #113

#113 moves ext.bootstrap.styles and ext.bootstrap.scripts out of ParserAfterParse, where the
decision is baked into the skin-agnostic parser cache, into the OutputPageParserOutput hook, where
the active skin is known, and skips them for skins that ship Bootstrap themselves. That removes the
duplicate Bootstrap CSS. The duplicate Bootstrap JavaScript remains, and it causes a real
bug. Recording what was measured, since the fix is bigger than #113.

Why the JavaScript still doubles

ext.bootstrapComponents.carousel.fix, .modal.fix, .popover.fix and .tooltip.fix each declare
ext.bootstrap.scripts as a ResourceLoader dependency, so any page using one of those components
pulls Extension:Bootstrap's JavaScript in regardless of skin. Skipping it in the hook, as #113 does,
does not stop that.

What each skin provides, and what breaks

Checked in a browser on a MediaWiki 1.43 install running all three skins with Extension:Bootstrap 6.0.0:

skin	Bootstrap CSS	Bootstrap JS	window.bootstrap	duplicate JS
Chameleon	own clone, zzz.ext.bootstrap.styles	loads ext.bootstrap.scripts itself	yes	no, same module name, ResourceLoader deduplicates
Medik	bundled bootstrap.min.css	bundled bootstrap.bundle.min.js, in skins.medik.js	yes	yes
Tweeki	compiled into tweeki.css	Bootstrap 5.3.3, inside the tweeki.js bundle	no	yes

Chameleon is fine: it requests the same module name, so ResourceLoader serves one copy. Medik and
Tweeki both end up with two live copies, and on both the accordion stops working.

Each copy registers Bootstrap's collapse data API on document, so one click is handled twice.
Measured on a page with an accordion and a modal, versus a page with only an accordion:

• one copy: 12 click listeners on document from one script, events hide, hidden, panel closes
• two copies: 24 click listeners from two scripts, events hide, show, hidden, shown, panel unchanged

Two details worth recording. Medik bundles v5.3.8, the same version Extension:Bootstrap ships, so
this is not a version clash: two copies of an identical build break it. And Tweeki's bundle registers
the data API without ever assigning window.bootstrap, so the global is not a reliable test for
whether a skin already ships Bootstrap. On a Tweeki page carrying both copies, window.bootstrap
resolves to 5.3.8 while $.fn.collapse resolves to 5.3.3: two different Bootstraps, reachable by two
different paths, on one page.

The direction a fix would take

Module::getDependencies( ?Context $context ) receives the active skin, so a module owned by this
extension could point the four fix modules at whichever module supplies Bootstrap for that skin, and
at ext.bootstrap.scripts otherwise. Core supports this deliberately: FileModule omits
dependencies from its version hash as "provided via startup module", and Context::getHash() varies
by skin, so a skin-varying dependency is intended usage rather than a trick.

Tweeki needs a second piece. Since its bundle exposes no global, this extension's scripts cannot see
it. Its Bootstrap is reachable through jQuery: Bootstrap 5 registers every component in jQuery's
plugin system when jQuery is present, and $( el ).collapse( 'toggle' ), $( el ).tooltip( 'show' )
and $( el ).modal( 'show' ) were confirmed to drive Tweeki's copy with no global present.

The open design question is how this extension should learn which module supplies Bootstrap for a
given skin. Hardcoding the names couples it to skin internals that are not a published contract. The
alternative is to let skins declare it, via an attributes entry in skin.json read through
ExtensionRegistry::getAttribute(), which puts the fact in the hands of the skin that knows it. That
needs the skins to opt in, so it does not help a Bootstrap 5 skin that declares nothing.

I am not taking this further right now, to keep #113 focused on the CSS half. Anyone picking it up
should know the Medik and Tweeki accordion breakage is the concrete symptom to test against.

A correction to the notes above

The earlier claim that the provided Bootstrap's version is not verifiable is too strong. It is
readable at runtime, from window.bootstrap or from Bootstrap's jQuery plugin bridge, whichever a
skin exposes, though a skin can expose neither. What is not possible is checking it at install or
configuration time, which is where a mismatch could actually be prevented.

_{AI-authored — Claude Code, Opus 4.8 (max); investigation steered by @malberts over several
rounds and reviewed by him before posting; the per-skin table, the duplicate-copy measurements and
the jQuery interface were checked in a browser on a local MediaWiki 1.43 install, and the fix
direction is read from MediaWiki source rather than built or tested.}

[malberts]

Closing with the 6.1.0 release, which resolves the harm this issue describes, under the revised direction from the 2026-07-16 summary comment above rather than the original title.

Fixed in 6.1.0 (#123, building on the resolver from #124):

• Skins that provide their own Bootstrap no longer also load Extension:Bootstrap's copy. Medik and Tweeki keep a single Bootstrap, which fixes the doubled data-api handling (the JS event issues referenced via Migrate to Bootstrap 5.3 #93): navbar and action dropdowns, accordions and other click-driven components work again.
• Chameleon no longer receives the Bootstrap stylesheet twice (its zzz.ext.bootstrap.styles clone cannot be deduplicated against ext.bootstrap.styles, so BootstrapComponents now skips adding the latter there).
• Component initialization resolves Bootstrap from window.bootstrap or from the jQuery plugin bridge, so it also works on skins like Tweeki that expose no global.

Deliberately kept: the hard composer dependency on Extension:Bootstrap. The constraint is the version-compatibility lever: it pins which Bootstrap major BootstrapComponents targets and rejects an incompatible future Extension:Bootstrap. Since 6.1.0 loads nothing from Extension:Bootstrap on skins that provide their own, the remaining cost of the requirement on such wikis is the composer install footprint.

If a concrete need arises to run BootstrapComponents without Extension:Bootstrap installed at all, that is best filed as a new, narrower issue.

Result of the 6.1.0 release work with @malberts.
Context: this issue's thread, PRs #113, #122, #123 and #124, and the BootstrapComponents, Chameleon, Medik and Tweeki codebases.
_{Written by Claude Code, Fable 5}