BetterDiscord Addon Analysis

require() usage — polyfill retirement list

BetterDiscord has no real require; these modules are served by the polyfill. Each list names the plugins to migrate before it can be removed. Plugins also reach the same environment without require — see Environment coupling below. Downloads is the combined cumulative lifetime store downloads of the plugins listed — the installed-base weight of each migration, not active users.

Δ compares against the 2026-08-24 snapshot.

Environment coupling

The rest of what plugins reach for outside the addon sandbox: Node/Electron globals touched directly rather than through the require polyfill, and the React entry points that break on a Discord React bump.

Style injection — API vs hand-rolled API winning

The same question createRoot answers for React, for stylesheets: are plugins using the API BD offers, or doing it by hand? BdApi.DOM.addStyle injects a managed <style> that BD removes on unload; a hand-rolled document.createElement("style") is the plugin's own to clean up. Here the API is ahead — the healthy direction. (React's virtual createElement("style") is not counted; only a real DOM node is.)

BdApi usage by namespace

Calls resolved through aliases, destructuring, and new BdApi() instances. Use this to weigh the impact of API changes.

Removal shortlist — 27 of 150 declared members go uncalled

The usage table above measures how big a change's blast radius is; this one asks whether there is any blast radius at all. BdApi's declared surface comes from a manifest generated from BetterDiscord core (v1.13.14, commit 5f9d3b0f, read 2026-07-16) by scripts/surface.ts, and is diffed against what the corpus actually calls. Members are the names addons type, not the classes behind them — AddonAPI is exposed twice, as BdApi.Plugins and BdApi.Themes, and both are counted. Names outside BD's own classes (BdApi.React, BdApi.ReactDOM) are opaque and never judged here; their members are Discord's.

Uncalled in the store corpus only — plugins outside the store, and the private plugins every user writes, are not visible to this analysis. Read it as "no store addon would notice", not "nothing would break". Two known blind spots keep this list honest: plugins built on BDFDB or ZeresPluginLibrary route calls through the library, and BdApi.Patcher.* computes its member name at runtime, so no member of that namespace can be credited from it.

Calls to members that do not exist

The other direction: chains the corpus calls that BD core does not declare. This replaces a hand-maintained list, which could only ever drift out of sync with core.

This is dead code, not live breakage. All of it is one library — DevilBro/0BDFDB — and every call sits behind a feature-detection guard (typeof BdApi.enableSetting == "function", or an is-array check for BdApi.settings), so the code path is simply never taken. Nothing is broken today and removing these names from core would change nothing. A headline of the form "N plugins call a removed API" would be wrong.

Plugin shape — the v1 lifecycle BD still honors

What plugins define, counted at definition sites via the AST rather than by name: grep -l getName finds 66 plugins, but 11 of those are .getName() calls on Discord modules, which are not plugin lifecycle at all. A plugin that defines a member on a nested helper class as well as on itself is counted once. Downloads weighs each member by the cumulative lifetime store downloads of its defining plugins — the installed base a removal would touch, not active users.

observer is the one to act on. To serve the 6 plugins that define it, core constructs a document-wide MutationObserver (observe(document, {childList: true, subtree: true})) and dispatches every mutation to every loaded plugin — a cost every user pays on every DOM change, whether or not they run any of those 6. observer, onSwitch and load are marked removal candidates, not deprecated: BD has not deprecated them, and this report is not the place to announce that it has. (load is redundant — a plugin's code already runs at require/eval time and in its constructor, so anything it does can move there — but many plugins never migrated.) The get-family is genuinely deprecated — the meta block supersedes it, and core only consults these overrides if the instance defines them.

Discord internals reliance

What the ecosystem pulls out of Discord's webpack (module keys, exported strings, prototype keys, stores, display names) and which methods it patches. This is the surface that breaks on Discord updates — the highest-demand entries are candidates for a stable CommonModules offering.

These are floors, not totals. 48 of 209 plugins reach Discord through a library object rather than BdApi directly (BDFDB 47 · 15.4M downloads, ZeresPluginLibrary 1 · 37.9K downloads) — their webpack lookups and patches are attributed to the library, so they are invisible to the tables below. In installed-base terms the blind spot is 15.4M of the corpus's 55.7M cumulative downloads — 28% of every copy ever installed routes its Discord access through a library these tables cannot see into. Detection is a runtime read of the library global, not a string mention: the four ex-dependents whose changelogs still say "no longer relies on ZeresPluginLibrary" are correctly excluded. Both libraries are unmaintained — ZeresPluginLibrary was deprecated over a year ago — so every dependent is also a plugin that will need rewriting when the library finally breaks.