Fix TypeScript compilation errors in common.ts

[sean-mcmanus]

Fix by Copilot with Claude Opus 4.8 in VS Code.

Summary

Fixes four TypeScript errors across two files that were breaking the build:
three in src/common.ts and one in .scripts/common.ts. All were caused by
missing type information — an uncallable namespace import and several
implicitly-any parameters that violate the project's strict settings.

Errors fixed

1. src/common.ts — which is not callable (TS2349)

This expression is not callable.
  Type 'typeof which' has no call signatures.

whichAsync invoked the which module directly: which(name, ...). The module
was imported with a namespace import:

import * as which from "which";

@types/which v2 declares the module using export = which, where which is a
callable function (CommonJS-style export). Under the current TypeScript rules, a
namespace-style import (import * as) of an export = value cannot be called or
constructed, because doing so would fail at runtime when esModuleInterop is off
(this project does not enable it). TypeScript surfaces this as "Type 'typeof
which' has no call signatures."

Fix: use an import-require binding, which maps directly onto the CommonJS
export = shape and is callable:

import which = require("which");

2 & 3. src/common.ts — implicit any callback parameters (TS7006)

Parameter 'err' implicitly has an 'any' type.
Parameter 'resolved' implicitly has an 'any' type.

The which callback parameters had no annotations. Once the import was fixed so
the call resolves to a typed overload, the parameters were annotated to match the
@types/which async-first overload:

which(name, path ? { path } : {}, (err: Error | null, resolved: string | undefined) => {
    ...
});

4. .scripts/common.ts — implicit any filter parameter (TS7006)

Parameter 'l' implicitly has an 'any' type.

The unhandledRejection handler split a stack trace and filtered the lines, but
the filter callback parameter was untyped. Since String.prototype.split returns
string[], the parameter is annotated as string:

.filter((l: string) => !l.includes('node:internal') && !l.includes('node_modules'))

Why these surfaced

All four are strict / noImplicitAny violations. The namespace-import issue is
a correctness fix (the previous form would have thrown at runtime if it had
compiled); the rest are purely type annotations that restore proper inference
without changing any runtime behavior.

Testing

• tsc no longer reports errors in either file (verified — 0 errors).
• yarn run lint passes.
• No runtime behavior change: the which call site is functionally identical,
  and the added annotations only describe existing values.

[Copilot]

Pull request overview

This PR resolves TypeScript strict compilation errors by fixing the import shape for the CommonJS which module and adding missing parameter type annotations so the project builds cleanly under noImplicitAny.

Changes:

• Switch which import in Extension/src/common.ts to an import = require() form so it’s callable under the project’s TS module settings.
• Add explicit types to callback/filter parameters to eliminate implicit-any errors.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
Extension/src/common.ts	Fixes which import/call typing and annotates callback parameters to satisfy strict compilation.
Extension/.scripts/common.ts	Annotates a filter callback parameter to avoid implicit-any under strict settings.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.