test/exports.test.ts (1)

148-161: Good test coverage for the primary fix scenarios.

The new tests properly validate the core issue where generics in value expressions were incorrectly parsed. Consider adding a test for nested generics to ensure complete coverage:

💡 Optional: Additional test case for nested generics

"export const nested = new Map<string, Handler<A, B>>()": {
  type: "declaration",
  name: "nested",
  names: ["nested"],
},

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/exports.test.ts` around lines 148 - 161, Add a test that covers nested
generics so the parser won't mis-handle inner generic angle brackets;
specifically add a declaration case for a symbol like "nested" using a nested
generic value expression such as new Map<string, Handler<A, B>>() (refer to
existing test patterns like APP_MODE_MAP, result, and a/b) to ensure the test
verifies the parser correctly recognizes "nested" and its names array contains
["nested"] and the type is "declaration".

src/analyze.ts (1)

439-451: Pattern change is optional for robustness; edge case does not occur in the current codebase.

The fix correctly distinguishes generic syntax from comparison operators by checking if < is preceded by an identifier character. However, the regex /[A-Za-z_$]/ excludes digits, which would theoretically prevent recognition of generics on identifiers ending in numbers (e.g., Handler2<A, B>, ES6Map<K, V>). A search of the codebase found no existing instances of this pattern, so this is not a practical issue. That said, extending the regex to /[\w$]/ or /[A-Za-z0-9_$]/ would be a defensive improvement for future-proofing the logic.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/analyze.ts` around lines 439 - 451, The check that decides whether a '<'
starts a generic uses the regex /[A-Za-z_$]/ which ignores digits and thus fails
for identifiers ending in numbers; update the condition used where
inTypeAnnotation and char === "<" and depth === 0 ... (the block manipulating
angleDepth, inTypeAnnotation, char, depth, extraNamesStr) to use a character
class that includes digits (e.g., use \w or explicitly A-Za-z0-9_$) so
identifiers like Handler2<A,B> or ES6Map<K,V> are recognized as generics and
angleDepth is incremented correctly.

test/exports.test.ts (1)

148-175: Optional: add _/$ generic opener fixtures to fully lock the heuristic.

Since the opener rule allows identifier starts [A-Za-z_$], consider adding fixtures like export const x = _Factory<T>() and export const y = $Factory<T>() to guard those branches explicitly.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/exports.test.ts` around lines 148 - 175, Add explicit test fixtures that
cover generic-openers beginning with '_' and '$' to lock the heuristic: create
declarations like variables x and y that call generic factories whose names
start with '_' and '$' (e.g., use identifiers x and y and factory names _Factory
and $Factory with a generic parameter, such as x = _Factory<T>() and y =
$Factory<T>()), and add them alongside the existing export const cases
(reference symbols APP_MODE_MAP, result, nested, m) in the same test file so the
parser branches for '_' and '$' are exercised.