pre-push blocks pushes on a typecheck error in unmodified src/bus/global.ts

Start with packages/opencode/src/bus/global.ts and the repository’s pre-push configuration, then run bun typecheck from a clean install while recording the resolved TypeScript and @types/node versions. Compare the affected and clean environments to separate the override failure from installation skew. Done means the pre-push typecheck is reliable for contributors using the locked toolchain, without requiring --no-verify.

What happens

git push is blocked by the pre-push hook because bun typecheck fails on code the contributor did not touch — packages/opencode/src/bus/global.ts:14, which is unmodified on origin/main:

Type 'any[]' is not assignable to type '[event: GlobalEvent]'.
  Target requires 1 element(s) but source may have fewer.

14   override emit(eventName: "event", event: GlobalEvent): boolean {
                   ~~~~~~~~~

Found 1 error in src/bus/global.ts:14

Failed:    @altimateai/altimate-code#typecheck
 ERROR  run failed: command  exited (2)
error: "turbo" exited with code 2
husky - pre-push script failed (code 2)
error: failed to push some refs to 'https://github.com/AltimateAI/altimate-code.git'

The code

class GlobalBusEmitter extends EventEmitter<{
  event: [GlobalEvent]
}> {
  override emit(eventName: "event", event: GlobalEvent): boolean {

With the generic EventEmitter<T> form, the base declares emit across a set of overloads including (eventName: string | symbol, ...args: any[]). An override has to be assignable to all of them, and this narrow one-event signature is not — hence any[] not assignable to [event: GlobalEvent].

Why it matters

The hook is the only pre-push gate in the repo, and this failure is indistinguishable from a real error introduced by the contributor. The natural workaround is git push --no-verify, which disables the gate entirely for that push. Anyone who hits it once tends to keep using it.

Important caveat: not universally reproducible

I could not reproduce it. On a clean worktree at origin/main:

Same pinned @types/node as the catalog specifies, and global.ts typechecks clean. So this is toolchain- or install-dependent, not a straightforward break on main — which also fits main's CI, where the TypeScript job passes.

That makes the version skew itself part of the bug: two contributors on the same commit get different answers from the same command, and the one who gets the error has no way to tell it apart from a real one.

Suggested direction

Two things worth separating:

1. Make the override version-robust so it satisfies the base overload set regardless of which @types/node resolves — either by widening the override to the generic signature, or by dropping the emit override in favour of a named method (e.g. publish(event)) that stamps the id and delegates to super.emit("event", event).
2. Work out why the resolved toolchain differs between machines on the same lockfile, since a non-deterministic typecheck undermines the hook whatever global.ts looks like.

Reproduction details from an affected machine (resolved @types/node, @typescript/native-preview, and whether node_modules predates the current lockfile) would pin down which of the two is doing the damage.

Unrelated, noticed while looking

There is no .husky/pre-commit. core.hooksPath is .husky/_, whose generated pre-commit shim exits 0 when no .husky/pre-commit exists, so commits currently run no checks at all. Flagging in case that is unintentional — happy to split it out.