Detector::Javascript::Oak

Oak ships no package.json of its own — it's a Deno-native framework — so the reliable signal is the import specifier itself:

• the JSR package, import { Router } from "@oak/oak", including the bare jsr:@oak/oak specifier form.
• the legacy URL import, import { Router } from "https://deno.land/x/oak@v.../mod.ts" (any version, any subpath — the bare "deno.land/x/oak" substring covers all of them). Both forms are quoted strings rather than anchored to from/ require( so the same signal also fires inside a Deno import map (deno.json/deno.jsonc/import_map.json), where the specifier is a bare JSON key/value: "imports": { "@oak/oak": "jsr:@oak/ oak@^17.1.0" } or "oak/": "https://deno.land/x/oak@v12.6.1/".

The tech name without needing an instance, so the registry can be read off the classes themselves rather than from a parallel list.

Cheap filename-only filter the detector pass uses to skip detect on files the detector cannot possibly match. The default true preserves prior behavior (every detector runs on every file). Override with the same predicate the body of detect starts with — e.g., filename.ends_with?(".py") for a Python framework detector — so the detector loop avoids the detect dispatch on files outside the detector's language.

On large codebases (saleor's 4255 .py files) this lifts ~100 virtual detect calls per file out of the hot loop because most detectors' inner first-line is exactly this kind of cheap filename check.