Feature request: expose .env assignments as graph nodes (name + value + file)
Version: v0.9.0 (linux-amd64-portable), index mode=full
Priority: minor — a convenience, not a blocker. File content is retrievable via get_code_snippet, so this is about queryability, not access.
Related: #1077 (.env.* sibling variants collide on qualified_name) — that one is a blocker, and it must land first for this to be useful, since today only one variant per directory survives.
Context
dotenv files are indexed and their content is retrievable — get_code_snippet on a .env File node returns the file body correctly.
What's missing is that env assignments are not graph nodes, so they can't be queried — only fetched as raw text and parsed client-side.
Current behaviour
The only Variable nodes carrying env-style names come from code, never from .env files. In a React/webpack repo, a query for env-prefixed variables returns only names destructured in JS config files:
MATCH (v:Variable) WHERE v.name CONTAINS "REACT_APP" RETURN v.name, v.file_path
→ hits only in config/webpack.dev.js (JS destructuring), never in any .env file — even though the .env files define many more such variables.
Request
Expose each .env assignment as a node carrying name + value + file_path, so consumers can do:
MATCH (v:EnvVar) WHERE v.name = "REACT_APP_API_URL" RETURN v.value, v.file_path
instead of fetching every .env file's text and re-parsing it.
The upstream tree appears to already contain the relevant machinery (pass_envscan, extract_env_accesses), so this may be mostly a matter of emitting nodes from an existing pass.
Use case
We build an integration-knowledge graph across a multi-repo estate. Resolving a frontend's API-URL env var → its actual URL is what binds that frontend to the backend service it calls. Env files are where that binding lives, and a graph representation would let us derive it with one query per estate rather than fetch-and-parse per repo.
Being able to distinguish values per environment (.env.uat vs .env.production) is the whole point — which is why #1077 must be fixed first.
Feature request: expose
.envassignments as graph nodes (name + value + file)Version: v0.9.0 (linux-amd64-portable), index
mode=fullPriority: minor — a convenience, not a blocker. File content is retrievable via
get_code_snippet, so this is about queryability, not access.Related: #1077 (
.env.*sibling variants collide on qualified_name) — that one is a blocker, and it must land first for this to be useful, since today only one variant per directory survives.Context
dotenv files are indexed and their content is retrievable —
get_code_snippeton a.envFilenode returns the file body correctly.What's missing is that env assignments are not graph nodes, so they can't be queried — only fetched as raw text and parsed client-side.
Current behaviour
The only
Variablenodes carrying env-style names come from code, never from.envfiles. In a React/webpack repo, a query for env-prefixed variables returns only names destructured in JS config files:→ hits only in
config/webpack.dev.js(JS destructuring), never in any.envfile — even though the.envfiles define many more such variables.Request
Expose each
.envassignment as a node carrying name + value + file_path, so consumers can do:instead of fetching every
.envfile's text and re-parsing it.The upstream tree appears to already contain the relevant machinery (
pass_envscan,extract_env_accesses), so this may be mostly a matter of emitting nodes from an existing pass.Use case
We build an integration-knowledge graph across a multi-repo estate. Resolving a frontend's API-URL env var → its actual URL is what binds that frontend to the backend service it calls. Env files are where that binding lives, and a graph representation would let us derive it with one query per estate rather than fetch-and-parse per repo.
Being able to distinguish values per environment (
.env.uatvs.env.production) is the whole point — which is why #1077 must be fixed first.