[PR #2402] [MERGED] fix(javascript): keep configuration setting reads out of endpoints #5201

New issue

Closed

opened 2026-10-31 01:04:46 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:04:46 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2402
Author: @alfredo1491
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @morluto

Base: main ← Head: fix/javascript-configuration-get-endpoints

📝 Commits (4)

24b04f2 fix(javascript): keep configuration setting reads out of endpoints
67123bf fix(javascript): require the workspace host for configuration receivers
ccb9eb1 fix(javascript): preserve endpoints for local configuration hosts
f3397e0 fix(javascript): recognize default VS Code namespace imports

📊 Changes

4 files changed (+159 additions, -34 deletions)

View changed files

📝 src/domain/javascript/javascriptSemanticAnalysis.ts (+96 -10)
📝 src/domain/javascript/javascriptStaticAnalysisHelpers.ts (+6 -15)
📝 src/domain/javascript/javascriptStaticAnalysisState.ts (+2 -9)
📝 src/domain/webBundleAnalyzer.test.ts (+55 -0)

📄 Description

Problem

Static endpoint extraction treats the first literal argument of any *.get(...) call as an HTTP request path unless the receiver is a provable keyed collection (eb68761eb). VS Code extension bundles read settings through workspace.getConfiguration(section).get(key), so every setting key is reported as a network endpoint.

Running the published rea-agents@6.4.0 analyze-javascript-application on the Git extension bundled with VS Code (resources/app/extensions/git) returned 109 network endpoint nodes, nearly all of them setting names such as autofetchPeriod, blame.statusBarItem.enabled, and timeline.date. Static analysis of that extension's dist/main.js alone yields 173 network endpoint findings.

Change

classifyParsedJavaScriptOpenReceivers (the single owner of lexical receiver facts) now records a configuration fact for a .get call whose receiver is a getConfiguration(...) call:
- inline: vscode.workspace.getConfiguration("git").get("autofetch")
- through a binding whose only visible write is one unconditional initializer: let c = Mt.workspace.getConfiguration("git", uri), l = c.get("timeline.date"). Minifiers emit let here, so the proof uses the recorded writes (semanticStableInitializer) rather than the declaration kind, as tRPC client root resolution already does.
endpointArgument skips non-URL literals for that fact, in both application analysis and web bundle analysis (both consume the same facts).
Unchanged on purpose: reassigned, conditional, and shadowed receivers; URL/path literals (config.get("/v1/settings")); and other possible base-URL clients such as api.get("users").
Cleanup: the receiver fact union was duplicated in three modules; javascriptStaticAnalysisHelpers.ts and javascriptStaticAnalysisState.ts now import JavaScriptOpenReceiverFact.

Measurements

analyzeJavaScriptStaticSource on VS Code's extensions/git/dist/main.js (warm, same host):

	before	after
network endpoints	173	7
analysis time	2.10 s	2.10 s

The 7 remaining are not provable by this rule and are left untouched: (isTrusted ? getConfiguration(...) : e).get(...) receivers and VS Code Memento reads (globalState.get, workspaceState) — the latter could be a follow-up.

Verification

New test keeps configuration setting reads out of endpoints in both analyzers in src/domain/webBundleAnalyzer.test.ts covers positives and the kept cases above for both analyzers.
vitest run src/domain/webBundleAnalyzer.test.ts src/domain/javascript/ src/application/javascript/ (rebased on current main): 1415 passed.
npm run check:fast (typecheck + lint): passed.
Fast projects (domain services adapters composition conformance evaluation) on Windows 11 x64, Node 22.23.1: same 126 pre-existing failures as main on this host (missing locally built Windows native addon, /tmp paths, Windows-invalid file names), +1 passing test.

Unavailable coverage: boundary/acceptance projects and the real CLI run from source were not executed on this host because the Windows native addon cannot be built outside the Linux/MinGW lane; the before/after numbers come from the domain analyzer directly. No real-provider lanes apply.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2402 **Author:** [@alfredo1491](https://github.com/alfredo1491) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/javascript-configuration-get-endpoints` --- ### 📝 Commits (4) - [`24b04f2`](https://github.com/morluto/rea/commit/24b04f2a7a602666418a8260e25ec9b81508a7b9) fix(javascript): keep configuration setting reads out of endpoints - [`67123bf`](https://github.com/morluto/rea/commit/67123bf5debab3ddbb83f0c8bd1f832c9efc6965) fix(javascript): require the workspace host for configuration receivers - [`ccb9eb1`](https://github.com/morluto/rea/commit/ccb9eb1b4adad57967758da65761c751443c4833) fix(javascript): preserve endpoints for local configuration hosts - [`f3397e0`](https://github.com/morluto/rea/commit/f3397e02b25884899aaa1e77085e8fc103578652) fix(javascript): recognize default VS Code namespace imports ### 📊 Changes **4 files changed** (+159 additions, -34 deletions) <details> <summary>View changed files</summary> 📝 `src/domain/javascript/javascriptSemanticAnalysis.ts` (+96 -10) 📝 `src/domain/javascript/javascriptStaticAnalysisHelpers.ts` (+6 -15) 📝 `src/domain/javascript/javascriptStaticAnalysisState.ts` (+2 -9) 📝 `src/domain/webBundleAnalyzer.test.ts` (+55 -0) </details> ### 📄 Description ## Problem Static endpoint extraction treats the first literal argument of any `*.get(...)` call as an HTTP request path unless the receiver is a provable keyed collection (eb68761eb). VS Code extension bundles read settings through `workspace.getConfiguration(section).get(key)`, so every setting key is reported as a **network** endpoint. Running the published `rea-agents@6.4.0` `analyze-javascript-application` on the Git extension bundled with VS Code (`resources/app/extensions/git`) returned 109 `network` endpoint nodes, nearly all of them setting names such as `autofetchPeriod`, `blame.statusBarItem.enabled`, and `timeline.date`. Static analysis of that extension's `dist/main.js` alone yields 173 network endpoint findings. ## Change - `classifyParsedJavaScriptOpenReceivers` (the single owner of lexical receiver facts) now records a `configuration` fact for a `.get` call whose receiver is a `getConfiguration(...)` call: - inline: `vscode.workspace.getConfiguration("git").get("autofetch")` - through a binding whose only visible write is one unconditional initializer: `let c = Mt.workspace.getConfiguration("git", uri), l = c.get("timeline.date")`. Minifiers emit `let` here, so the proof uses the recorded writes (`semanticStableInitializer`) rather than the declaration kind, as tRPC client root resolution already does. - `endpointArgument` skips non-URL literals for that fact, in both application analysis and web bundle analysis (both consume the same facts). - Unchanged on purpose: reassigned, conditional, and shadowed receivers; URL/path literals (`config.get("/v1/settings")`); and other possible base-URL clients such as `api.get("users")`. - Cleanup: the receiver fact union was duplicated in three modules; `javascriptStaticAnalysisHelpers.ts` and `javascriptStaticAnalysisState.ts` now import `JavaScriptOpenReceiverFact`. ## Measurements `analyzeJavaScriptStaticSource` on VS Code's `extensions/git/dist/main.js` (warm, same host): | | before | after | |---|---|---| | network endpoints | 173 | 7 | | analysis time | 2.10 s | 2.10 s | The 7 remaining are not provable by this rule and are left untouched: `(isTrusted ? getConfiguration(...) : e).get(...)` receivers and VS Code `Memento` reads (`globalState.get`, `workspaceState`) — the latter could be a follow-up. ## Verification - New test `keeps configuration setting reads out of endpoints in both analyzers` in `src/domain/webBundleAnalyzer.test.ts` covers positives and the kept cases above for both analyzers. - `vitest run src/domain/webBundleAnalyzer.test.ts src/domain/javascript/ src/application/javascript/` (rebased on current main): 1415 passed. - `npm run check:fast` (typecheck + lint): passed. - Fast projects (`domain services adapters composition conformance evaluation`) on Windows 11 x64, Node 22.23.1: same 126 pre-existing failures as `main` on this host (missing locally built Windows native addon, `/tmp` paths, Windows-invalid file names), +1 passing test. Unavailable coverage: boundary/acceptance projects and the real CLI run from source were not executed on this host because the Windows native addon cannot be built outside the Linux/MinGW lane; the before/after numbers come from the domain analyzer directly. No real-provider lanes apply. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:04:46 +00:00