chore(deps): match CommonJS and template-literal imports in the shared-source scan

From the suppressed comment on Copilot's second pass of #1962. Under-
approximating is the dangerous direction here: a package the scan misses
never enters the candidate set, so its skew passes the guard silently.

Three forms went unmatched. `import x = require("pkg")` and a bare
`require("pkg")` are the ordinary import syntax in `.cts` — which the
previous commit just admitted to the scan, so leaving them out would have
been an inconsistency introduced by that widening. A dynamic import carrying
import attributes (`import("pkg", { with: … })`) was missed because the
pattern required the closing paren. A static template literal
(`import(\`pkg\`)`) was missed for want of a backtick in the quote class.

Backticks are accepted only in the *call* forms. A `from` clause requires a
string literal, so allowing them there would buy nothing while reopening the
prose hazard the anchored specifier pattern closes: inline code in comments
is written with backticks throughout this codebase, and admitting it inflated
the derived set from 18 names to 41 with prose fragments (`tools`,
`connect()`, `messages`). Inert today, since a name absent from every
lockfile contributes nothing — but a prose word colliding with a real package
name would silently widen the set. Pinned with a regression test.

The real set is unchanged at 18, so these forms add no package today; they
close the syntax against the one that arrives later.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HDdo1rNRVQnVRRdsqSrvG3
This commit is contained in:
cliffhall 2026-08-10 20:47:09 -04:00
commit 47e0ee059a

View file

@ -101,12 +101,25 @@ export function packageNameOf(specifier) {
return name;
}
// `from "x"` (import and re-export), a side-effect `import "x"`, and a dynamic
// `import("x")`. Only these three forms introduce a dependency's *types*.
// Every form that can introduce a dependency's *types* (Copilot, #1962).
// `import x = require("pkg")` and a bare `require("pkg")` matter because the
// shared trees may hold `.cts` sources, where that is the ordinary import
// syntax; and neither call form requires the closing paren, so an import
// attributes argument (`import("pkg", { with: … })`) can't hide the specifier.
//
// Backticks are accepted ONLY in the call forms, where a static template
// literal is legal. A `from` clause requires a string literal, so allowing
// backticks there would buy nothing while reopening the prose hazard the
// anchored specifier pattern exists to close — inline code in a comment is
// written with backticks throughout this codebase, and "…derived from
// `tools`…" would otherwise enter the candidate set as a package named
// `tools`. Inert today, but a prose word that collides with a real package
// name would silently widen the set.
const SPECIFIER_FORMS = [
/\bfrom\s*["']([^"']+)["']/g,
/\bimport\s+["']([^"']+)["']/g,
/\bimport\s*\(\s*["']([^"']+)["']\s*\)/g,
/\bfrom\s*["']([^"']+)["']/g, // import … from "x" / export … from "x"
/\bimport\s+["']([^"']+)["']/g, // side-effect import "x"
/\bimport\s*\(\s*["'`]([^"'`]+)["'`]/g, // dynamic import("x"[, opts])
/\brequire\s*\(\s*["'`]([^"'`]+)["'`]/g, // import x = require("x"), require("x")
];
/**