Skip to content

engine: resolve reads of module-level consts through their import binding - #1836

Merged
swapnilpaliwal-sd merged 2 commits into
apps/integration-0.1.9from
apps/typescript/imported-const-read-through-member-acces
Sep 30, 2026
Merged

swapnilpaliwal-sd merged 2 commits into
apps/integration-0.1.9from
apps/typescript/imported-const-read-through-member-acces

Conversation

@swapnilpaliwal-sd

Copy link
Copy Markdown
Contributor

A module-scope const read as X.m, f(X), in a template or as typeof X had no edge to its declaration. So impact fell back to [by name], which also matched same-named consts in sibling packages that import their own.

  • TS and JS engines: field_access rows for an identifier bound to a module variable, either directly or through an import (including export * barrels). A const that holds a function is left to the call edges.
  • TS: typeof X in a type is a read of X by the enclosing function, or by the module. A same-named parameter or local shadows it.
  • Bundle: places a field-access site that is a type reference (file and line).
  • impact.dl: a const handed to a route stays a route registration after its read resolves.
  • Tests: new golden 86-module-variable-reads with controls (shadowing, sibling package, function const). The module-level-const cases are extended for TS and added for JS; without the rules 10 of 12 checks fail. Other goldens are re-blessed and 4 case expectations move from [by name]/[in scope] to [resolved].

Checked: TS suite 100/100, JS 88/88; impact cases TS 214/214, JS 281/281, Java 306/306, Python 278/278, C# 207/207. On a 50k-LOC TS monorepo: call edges 10045 → 10045, resolved field access 2160 → 3562, index 27.2 s → 29.3 s, probes 47/74 → 47/74 (no regressions). The example const's impact went from 5 [by name] rows to 1 resolved row.

…ding

A module-scope const used as `X.m`, `f(X)`, in a template or under `typeof X`
had no data edge to its declaration, so impact matched it by name, including
same-named consts in sibling packages whose files import their own.

- TypeScript and JavaScript engines export field_access rows for an identifier
  the binder ties to a module variable, directly or through an import binding
  (across `export *` barrels); `typeof X` type queries bind through module scope,
  with a same-named parameter or local shadowing it.
- The bundle positions a field-access site that is a type reference.
- impact: a const the engine bound on a route line is still a registration.
- Goldens re-blessed: module consts read by name now carry known_edge reads.

Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
@swapnilpaliwal-sd

Copy link
Copy Markdown
Contributor Author

This conflicts with #1829 only in generated goldens: the .fields and .fields-oracle files for TypeScript tests 78 and 80. Don't hand-merge them. Rebase onto apps/integration-0.1.9, take either side, regenerate both tests' goldens from the merged engine with the TypeScript suite's update mode, and check that the diff shows only this PR's intended rows. Then run the full TypeScript engine suite.

The 78/80 goldens both sides regenerated are blessed again from the merged engine (the result differs from the
integration tip by exactly this PR's rows), and the two 86 tests gain the reads this PR resolves (module consts
read through their bindings); no resolved row is lost.

Co-authored-by: axiomcode-bot[bot] <334110751+axiomcode-bot[bot]@users.noreply.github.com>
@swapnilpaliwal-sd
swapnilpaliwal-sd merged commit 4933404 into apps/integration-0.1.9 Sep 30, 2026
12 checks passed
@swapnilpaliwal-sd
swapnilpaliwal-sd deleted the apps/typescript/imported-const-read-through-member-acces branch September 30, 2026 22:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant