Sub-finding from the #494 review (the #488 epic). The one-action-per-configured-file webjs check rule (packages/server/src/check.js) under-counts a TYPE-ANNOTATED arrow action: export const getThing: Handler = (id) => .... The arrow regex matches export const NAME = ...=>, but a : Type annotation between the name and = is not allowed for, so an annotated-arrow action is not counted. A configured TS file with one export async function plus one annotated-arrow action could slip past the lint.
Design / approach
Broaden the regex to allow an optional : Type annotation before the = (carefully, since a function-type annotation contains =>), or switch to a tiny lexical pass that finds export const NAME and classifies the RHS as a function (arrow / function-expression) vs a value. It is an advisory check (a false negative misses a flag, never a crash), so low urgency, but worth making airtight.
Acceptance criteria
Sub-finding from the #494 review (the #488 epic). The
one-action-per-configured-filewebjs checkrule (packages/server/src/check.js) under-counts a TYPE-ANNOTATED arrow action:export const getThing: Handler = (id) => .... The arrow regex matchesexport const NAME = ...=>, but a: Typeannotation between the name and=is not allowed for, so an annotated-arrow action is not counted. A configured TS file with oneexport async functionplus one annotated-arrow action could slip past the lint.Design / approach
Broaden the regex to allow an optional
: Typeannotation before the=(carefully, since a function-type annotation contains=>), or switch to a tiny lexical pass that findsexport const NAMEand classifies the RHS as a function (arrow / function-expression) vs a value. It is an advisory check (a false negative misses a flag, never a crash), so low urgency, but worth making airtight.Acceptance criteria
export const x: SomeType = (id) => ...is counted as a callable action by the rule.export const x: (n: number) => string = ...) does not break the parse.export const x: number = 5) is still NOT counted.