Every module that would not load

tabby-electron alone swallows seven require failures in empty catch blocks, so a module that would not resolve left no trace and surfaced later as something unrecognisable. Module._load is wrapped, so the throw is seen before any of those catches reach it, and the error is always rethrown — this observes, it does not change what happens next.

tabby-electron alone has seven try { var wnr = require(…) } catch { } blocks, and the plugin loader has its own. A module that failed to resolve left no trace and surfaced later as something unrecognisable — the documented case being a missing windows-process-tree presenting as Cannot read properties of undefined (reading 'getRegistryKey'), with nothing about process-tree anywhere.

Module._load is wrapped, so the throw is seen before any of those catches swallow it. Nothing changes at the seven call sites, third-party plugin code is covered without its cooperation, and the error is always rethrown — this observes, it does not alter what happens next.

• Deduped by request|code and capped at 32 distinct, because a failing require is often intentional: optional dependencies and platform probes fail by design. One line per distinct thing that could not load, not one per attempt.
• Records the requesting file, so the answer is "which package asked", and the boot phase, so a load failure lines up against the stall it caused.
• It immediately named a real one nothing had ever reported: macos-native-processlist, MODULE_NOT_FOUND, from tabby-electron during plugin loading — harmless on Windows, and previously invisible.
• module must stay in the renderer webpack externals — it is, beside fs — or require('module') resolves to a webpack shim, the wrapper never installs, and the whole thing silently does nothing.

• The source catalogue records no separate caveats for this entry. The implementation and evidence above define its scope.