[GH-ISSUE #1831] [Bug] JavaScript namespace re-exports are omitted from complete semantic graphs #613

Closed
opened 2026-10-15 18:26:39 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @shoyann on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1831

Before submitting

  • I searched open and closed issues and pull requests for related reports.
  • This uses generated local source files without credentials or private targets.

Area

Evidence, artifacts, or reconstruction; JavaScript semantic application graphs.

Observed behavior

export * as ns from "./dep.mjs" produces no semantic re-export relationship and an empty exported-name inventory, while semantic and application-graph coverage report complete. The ordinary static resource dependency edge is present, so this is specifically a semantic export omission.

Minimal reproduction

After installing dependencies and building the source checkout:

fixture=$(mktemp -d)
printf '%s\n' '{"name":"namespace-export-repro","type":"module","main":"main.mjs"}' > "$fixture/package.json"
printf '%s\n' 'export * as ns from "./dep.mjs";' > "$fixture/main.mjs"
printf '%s\n' 'export const value = 42;' > "$fixture/dep.mjs"
node --input-type=module -e 'import {pathToFileURL} from "node:url"; const m=await import(pathToFileURL(process.argv[1])); console.log(Object.keys(m), m.ns.value)' "$fixture/main.mjs"
node scripts/rea.mjs analyze-javascript-application "$fixture" --format json

Node reports the export name ns and value 42. In the REA result, the main.mjs source-module observation instead reports:

{
  "module_format": "esm",
  "import_relationships": 0,
  "export_relationships": 0,
  "export_names": [],
  "omitted_export_names": 0
}

The graph coverage is complete, and there is no semantic module_link_kind: "re-export" edge for the declaration. By contrast, ordinary export { value } from "./dep.mjs" and export * from "./dep.mjs" are represented.

Expected behavior

Retain one namespace re-export with source specifier ./dep.mjs, imported name *, exported name ns, and no local binding. Include ns in the module's export inventory, preserving the declaration's source range and artifact provenance.

Impact and scope

Namespace barrel modules can appear to export nothing in semantic graphs despite complete coverage. Consumers lose the declared public namespace and re-export evidence; the static file dependency itself is not missing.

Version and environment

  • REA source revision: 76e4153 (also reproduced on f178bf1c).
  • Node.js 24.18.0, npm 11.16.0, WSL Ubuntu x64.
  • Target: ordinary ESM JavaScript source files.
  • Interface: JavaScript application analysis CLI and shared semantic graph.
  • Earliest failure stage: semantic module-link projection.

Source-derived analysis

collectNamedExports in src/domain/javascript/javascriptSemanticProjection.ts handles ExportSpecifier but skips Babel's ExportNamespaceSpecifier. The existing module-link representation already supports the required re-export facts.

This differs from #1802 / #1827, which concern Electron API identity through bundler interop helper calls. I am preparing a focused fix with public workflow regressions.

Originally created by @shoyann on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1831 ### Before submitting - [x] I searched open and closed issues and pull requests for related reports. - [x] This uses generated local source files without credentials or private targets. ### Area Evidence, artifacts, or reconstruction; JavaScript semantic application graphs. ### Observed behavior `export * as ns from "./dep.mjs"` produces no semantic re-export relationship and an empty exported-name inventory, while semantic and application-graph coverage report `complete`. The ordinary static resource dependency edge is present, so this is specifically a semantic export omission. ### Minimal reproduction After installing dependencies and building the source checkout: ```sh fixture=$(mktemp -d) printf '%s\n' '{"name":"namespace-export-repro","type":"module","main":"main.mjs"}' > "$fixture/package.json" printf '%s\n' 'export * as ns from "./dep.mjs";' > "$fixture/main.mjs" printf '%s\n' 'export const value = 42;' > "$fixture/dep.mjs" node --input-type=module -e 'import {pathToFileURL} from "node:url"; const m=await import(pathToFileURL(process.argv[1])); console.log(Object.keys(m), m.ns.value)' "$fixture/main.mjs" node scripts/rea.mjs analyze-javascript-application "$fixture" --format json ``` Node reports the export name `ns` and value `42`. In the REA result, the `main.mjs` source-module observation instead reports: ```json { "module_format": "esm", "import_relationships": 0, "export_relationships": 0, "export_names": [], "omitted_export_names": 0 } ``` The graph coverage is `complete`, and there is no semantic `module_link_kind: "re-export"` edge for the declaration. By contrast, ordinary `export { value } from "./dep.mjs"` and `export * from "./dep.mjs"` are represented. ### Expected behavior Retain one namespace re-export with source specifier `./dep.mjs`, imported name `*`, exported name `ns`, and no local binding. Include `ns` in the module's export inventory, preserving the declaration's source range and artifact provenance. ### Impact and scope Namespace barrel modules can appear to export nothing in semantic graphs despite complete coverage. Consumers lose the declared public namespace and re-export evidence; the static file dependency itself is not missing. ### Version and environment - REA source revision: `76e4153` (also reproduced on `f178bf1c`). - Node.js 24.18.0, npm 11.16.0, WSL Ubuntu x64. - Target: ordinary ESM JavaScript source files. - Interface: JavaScript application analysis CLI and shared semantic graph. - Earliest failure stage: semantic module-link projection. ### Source-derived analysis `collectNamedExports` in `src/domain/javascript/javascriptSemanticProjection.ts` handles `ExportSpecifier` but skips Babel's `ExportNamespaceSpecifier`. The existing module-link representation already supports the required re-export facts. This differs from #1802 / #1827, which concern Electron API identity through bundler interop helper calls. I am preparing a focused fix with public workflow regressions.
bsakaguchi 2026-10-15 18:26:39 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#613
No description provided.