revenge-plugins/docs/shared-modules-audit.md

Shared modules audit (classic revenge-plugins)

Date: 2026-08-16 Scope: /root/revenge-plugins only (Next repo not covered). Audit only — no code changed.

Goal: (1) give a reference sheet of what shared/ already offers so new/edited plugins reach for it instead of reinventing, and (2) list concrete cases where 2+ plugins built the same thing independently, so we know what's actually worth promoting to shared/ next.

1. Reference: what's already in shared/ and who uses it

Module	What it does	Adoption
ui/table.ts	TableRow/TableRowGroup/TableSwitchRow/TableRadioRow — Discord's redesigned settings rows, falling back to legacy Forms.Form*	24 files — well adopted, the default for any settings screen
ui/SettingsScaffold.tsx	ScrollView + bottom padding wrapper for a plugin's settings screen	19 files — well adopted
lib/color.ts	isValidHex, normalizeHex, resolveSemanticColor/resolveSemanticColorSafe (theme-aware color token resolution)	17 files — well adopted
ui/NoteBox.tsx	Bordered callout box for explanatory settings text	15 files — well adopted
ui/PrimaryButton.tsx	Standard filled action button	9 files — well adopted
lib/rawFind.ts	Walks window.modules directly for a module lookup that survives Revenge's negative-result caching	8 files
lib/patcher.ts	safePatch/applyPatches — one broken patch surface can't crash a whole plugin's onLoad	8 files — every plugin should use this for onLoad, worth spot-checking stragglers
lib/createElementIntercept.ts	Intercepts React.createElement/jsx/jsxs to replace or transform components that aren't exported and can't be after()-patched directly	7 files
lib/flux.ts	fluxSubscribe(event, cb, once?) with built-in unsubscribe	4 files
lib/waitFor.ts	Polls until a lazily-registered module/value appears, cancelable	4 files
ui/ListSection.tsx	Titled section of tappable rows with an empty-state note	3 files
lib/lazy.ts	Memoizing wrapper for a Metro lookup (resolve once, cache forever)	2 files — low adoption, worth checking for plugins hand-rolling the same "cache after first resolve" pattern
lib/patchRows.ts	patchRows(handler) — hooks the native chat row bridge (DCDChatManager.updateRows / RowManager.generate) so a handler sees every message row as JSON	Used by rose-utils, role-color-everywhere, message-logger
ui/ColorInput.tsx	Hex color field with swatches	1 file (radial-status) — see finding #2, this is the stale version

Note on patchRows.ts vs the member-list "UserRow" pattern below: these are unrelated despite similar names. patchRows is for the native chat message row bridge (JSON crossing to native code). The findByTypeNameAll("UserRow") pattern in finding #1 is a React component used in the member list / profile popout. Don't conflate them when extracting shared code.

2. Findings: duplicated or fork-worthy code

Finding 1 — staff-tags and custom-user-tags duplicate five files byte-for-byte

ui/IconPicker.tsx, ui/Icon.tsx, lib/icons.ts, and patches/tag.tsx are 100% identical between the two plugins (confirmed via diff, zero output). ui/ColorInput.tsx is also identical between the two but has drifted from shared/'s version — see finding 2.

patches/name.tsx, patches/details.tsx, patches/chat.ts, patches/profile.tsx are not byte-identical but are structurally the same patch applied twice: same target modules (DisplayName, UserRow, getTagProperties, UserProfilePrimaryInfo), same comments explaining why (e.g. "isn't a top-level export" copied verbatim into both profile.tsx files), and — not in scope for this audit, but worth knowing — the same latent bug in both: the existingTag.props?.type !== 0 guard can't tell "a real Discord tag is here" from "the other plugin already set a tag here," so having both plugins enabled causes one to silently clobber the other's tag on a user. That's the parked staff-tags/custom-user-tags coexistence design (separate task).

Recommendation: promote IconPicker.tsx, Icon.tsx, icons.ts to shared/ui and shared/lib as-is (genuine, no-decision-needed duplication). Leave the four patch files alone for now — their near-duplication is entangled with the coexistence bug fix, so refactor them together with that work rather than as a mechanical move.

Finding 2 — shared/ui/ColorInput.tsx is a stale stub; the real version lives unshared in two plugins

shared/ui/ColorInput.tsx is a minimal 2-swatch color field. staff-tags/src/ui/ColorInput.tsx and custom-user-tags/src/ui/ColorInput.tsx (identical to each other) are a fuller implementation: 28 swatches, hex↔RGB conversion helpers, uses normalizeHex from shared/lib/color. Only radial-status uses the shared stub today; everyone who needs a real color picker forked instead of upstreaming.

Recommendation: replace shared/ui/ColorInput.tsx's contents with the fuller version, point staff-tags/custom-user-tags/radial-status at it, delete the two local copies. Check radial-status's usage still renders correctly with the richer swatch set before removing its reliance on the stub.

Finding 3 — server-drawer forked createElementIntercept.ts instead of extending the shared one

server-drawer/src/patches/createElementIntercept.ts is a deliberate fork of shared/lib/createElementIntercept.ts, not accidental drift: it adds a collapseAncestors option (ancestor-collapsing, used to hide the guilds bar and reclaim its layout space) that the shared version doesn't have. 88 lines of diff, all additive on server-drawer's side.

Recommendation: this is a real capability gap in shared/, not a copy-paste duplication. Worth upstreaming collapseAncestors into shared/lib/createElementIntercept.ts and switching server-drawer back onto the shared module — but do it deliberately (it's shared infra used by 7 files across the repo; changing its behavior needs a look at every caller, not just server-drawer's four files that reference it).

Finding 4 — per-ID storage-map boilerplate repeated in at least 5 plugins

The pattern storage.<key> ??= {} followed by hand-written get/set/(sometimes remove) helpers for a per-user or per-ID settings map shows up independently in:

• staff-tags/src/lib/getTag.ts (tagSettings(id))
• custom-user-tags/src/lib/tags.ts (allTags(), getUserTag(), setUserTag(), removeUserTag())
• message-snippets/src/lib/snippets.ts
• radial-status/src/ui/Settings.tsx
• message-logger/src/index.ts (single-key, simpler case)

Recommendation: a small shared/lib/storageMap.ts exporting something like createStorageMap<T>(storage, key) → { get(id), set(id, value), remove(id), all() } would collapse ~15-20 lines per plugin into one call. Low risk, no behavior change, good first extraction to pair with finding 1's icon files.

Finding 5 — superseded, raidens-themes removed

Originally: raidens-themes/src/patches/settings.ts and rose-plugs/src/patches/settings.ts independently solved "pin a settings entry into Discord's native App Settings" with different, non-trivial APIs (272 lines of diff). raidens-themes was deleted from the repo on 2026-08-16, so this is no longer a duplication to reconcile — rose-plugs/src/patches/settings.ts is now the only implementation. Worth revisiting only if a future plugin wants the same capability; its SectionRow[] API (patches/settings.ts exports patchRosiesPlugsSection) is the one to build on, not extract into shared/ preemptively with no second consumer.

3. Suggested order if/when this gets acted on

1. Finding 4 (storage map) — mechanical, zero behavior change, unblocks nothing else.
2. Finding 1's static files (icons/IconPicker) — mechanical, identical code, low risk.
3. Finding 2 (ColorInput) — mechanical but touches 3 plugins' rendering, needs a visual check.
4. Finding 3 (createElementIntercept collapseAncestors) — real shared-infra change, needs care.
5. Finding 1's patch files (name/details/chat/profile) — do together with the parked staff-tags/custom-user-tags coexistence design, not standalone.
6. Finding 5 (settings pinning) — defer until a third consumer exists.