A theme library definition and its JavaScript file are both still sitting in this site's codebase right now, fully written, fully functional, and never loaded by anything. Not disabled, not commented out — just quietly disconnected from the one file that would tell Drupal to load them.
The fix that kept moving
A Superfish mobile-menu accessibility fix — add an aria-label and visible text to a toggle button, using a MutationObserver as a fallback if the button isn't in the DOM yet — went through three different delivery mechanisms in one evening. It started as a theme library (global-scripts, loading js/custom.js), then got pulled into a raw inline <script> tag in the Twig template. From there it got pulled back out and returned to the library, before finally moving a third time into a PHP hook (hook_page_attachments_alter()) assembling the same script as an inline render array value. Four distinct states, three actual moves, all within about ninety minutes.
What's still there
linkhub.libraries.yml still defines the library:
global-scripts:js:js/custom.js: {}dependencies:- core/jquery- jfeltkamp/cookiesjsr
And js/custom.js is still on disk, still containing the exact same fix function — same variable names, same fallback logic, same three-second observer timeout — as the version now living inline inside linkhub.theme. But linkhub.info.yml, the file that tells the theme which libraries to actually attach to every page, only lists one library now: linkhub/global-style. global-scripts isn't there. It was removed from that list during the first move away from the library approach, and never came back, even though the library definition and the JS file it points to were both left in place.
Why this is worth calling dead code, not just unused
A file with no references anywhere is unambiguous. This is subtler: the library is defined, correctly, in the file Drupal reads to know what libraries exist. It's just not attached anywhere — not in a theme's info file, not in a #attached array, not via {{ attach_library() }} in a template. Drupal will never load it, but nothing about scanning libraries.yml in isolation tells you that. You'd have to separately check every place a library can be attached and find none of them mention global-scripts — which is exactly the kind of cross-file check that's easy to skip when you're confident you already know the answer, or when the file just doesn't come up in the diff you're looking at.
How it survived being duplicated
The reason this is a byte-for-byte duplicate rather than just an orphaned definition is that nobody deleted the old delivery mechanism when they moved to a new one — each move added a new copy of the fix somewhere else and left the previous copy in place, unreferenced but intact. Three commits, three additions, zero deletions of the superseded version. That's a natural consequence of moving fast on a single script: the working version is whatever the last commit shipped, and cleaning up the ones that came before it is a separate, easy-to-defer task that has no functional consequence if skipped. The page renders correctly either way. Nothing breaks. The dead library just sits there, matching production behavior it no longer influences, waiting for someone to either delete it or — worse — half-remember it exists and re-enable it later, at which point the site would load the same accessibility fix twice from two different places.
What actually needs to happen
global-scripts and js/custom.js should either be deleted outright, since the fix they contain is live elsewhere now, or the inline-hook version should be removed and the library re-attached — one mechanism, not zero-referenced-plus-one-active. Leaving both in an inconsistent state doesn't cost anything today, but it's the kind of thing that costs someone real time later: a future audit of "what CSS/JS does this theme load" will find global-scripts in the library file, reasonably assume it's live, and go looking for where it's attached — only to find nothing, and either waste time confirming it's actually dead or, worse, not confirm it and report it as active when it isn't.