[PR #4838] [MERGED] fix(javascript): admit CommonJS bare scoped package directory resolution #6436

Closed
opened 2026-10-31 01:14:27 +00:00 by bsakaguchi · 0 comments
Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4838
Author: @prasad2512
Created: 10/17/2026
Status: ✅ Merged
Merged: 10/17/2026
Merged by: @morluto

Base: main ← Head: fix/scope-directory-resolution


📝 Commits (1)

  • 569e324 fix(javascript): admit CommonJS bare scoped package directory resolution

📊 Changes

3 files changed (+175 additions, -3 deletions)

View changed files

📝 docs/readme/README_fr.md (+1 -0)
📝 src/application/javascript/JavaScriptArtifactPathResolution.test.ts (+167 -0)
📝 src/application/javascript/JavaScriptArtifactPathResolution.ts (+7 -3)

📄 Description

Summary

Resolves #4632 by admitting CommonJS bare scoped package requests (e.g. require("@scope") and require("@scope/")) to resolve against locally inventoried node_modules/@scope package directories, index files, and package.json main entrypoints, while keeping ESM loader-owned export and invalid-specifier controls authoritative.

Problem and expected behavior

Previously, parseBarePackageRequest returned null for any specifier starting with @ that lacked a second segment (segments[1] === undefined || segments[1] === ""). This caused bareModuleCandidate to unconditionally treat valid CommonJS bare scoped requests like require("@scope") and require("@scope/") as external/invalid package names before any dependency directory or package metadata lookup occurred, even when node_modules/@scope/index.js or node_modules/@scope/package.json was present in the inventory.

Expected behavior:

  • CommonJS require("@scope") and require("@scope/") parse packageName as @scope and proceed through standard directory / package.json / index.js lookup.
  • When package.json with exports is present, require("@scope") resolves root exports while require("@scope/") respects exports encapsulation (matching Node's ERR_PACKAGE_PATH_NOT_EXPORTED).
  • In ESM (moduleKind === "import"), bare @scope without a slash remains an invalid module specifier (ERR_INVALID_MODULE_SPECIFIER), while @scope/ continues to be evaluated by loader-owned exports/metadata lookup.
  • Truly invalid specifiers (@ and @/) remain rejected as external.

Change and scope

  1. In src/application/javascript/JavaScriptArtifactPathResolution.ts (parseBarePackageRequest):
    • Reject truly invalid names where packageName === "@".
    • For scoped specifiers (specifier.startsWith("@")), if a package segment exists, join as ${packageName}/${packageSegment}.
    • For scope-only specifiers without a second segment:
      • CommonJS admits them with packageName = segments[0].
      • ESM rejects specifier === "@scope" (without a trailing slash) as invalid module specifier (return null).
      • ESM admits specifier === "@scope/" with packageName = segments[0] to allow loader-owned exports evaluation.
  2. In src/application/javascript/JavaScriptArtifactPathResolution.test.ts:
    • Added scoped package directory and specifier resolution suite covering:
      • CommonJS require("@scope") and require("@scope/") resolving to node_modules/@scope/index.js.
      • CommonJS require("@scope-main") and require("@scope-main/") resolving to package.json main: "entry.js".
      • CommonJS require("@scope") resolving root exports, while require("@scope/") stays external/unmatched against . exports.
      • ESM import "@scope" staying external (invalid specifier), while import "@scope/" stays external/unmatched.
      • Controls: @ and @/ staying external.

Contract and boundary impact

  • Semantic owner and earliest changed stage: src/application/javascript/JavaScriptArtifactPathResolution.ts (parseBarePackageRequest)
  • Contribution scope fit and linked maintainer decision: not applicable (bug fix within existing JavaScript path resolution boundary)
  • CLI and MCP/tool-catalog contract: none
  • Provider, bridge, target-format, or platform compatibility: all platforms
  • Evidence, artifact, provenance, or reconstruction contract: preserves exact dependency resolution status and resolved paths
  • Target selection, authority, upstream behavior, and cleanup details (if applicable): none
  • Generated metadata (docs/public/product-catalog.json), package, or installation impact: none

Expected effects:

  • Read existing files or captured data.
  • Launch or attach to a process.
  • Inject instrumentation or run scripts/code.
  • Change process memory, registers, files, or configuration.
  • Contact network services.
  • Recover protected code or work around protections.
  • Documentation or usability only; no target interaction.
  • Not sure yet; investigation or maintainer guidance needed.

Evidence and regression coverage

  • Tests added or updated: src/application/javascript/JavaScriptArtifactPathResolution.test.ts
  • Base reproduction or other evidence: Verified against Node.js v24.20.0 native require.resolve and import.meta.resolve behaviors.
  • User-visible CLI/MCP output (if applicable): none
  • Remaining proof gaps: none

For evidence-bearing changes:

  • Observed, derived, and inferred claims remain distinguishable.
  • Artifact identity, source provenance, and failed attempts remain preserved.
  • Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Validation performed

  • npm run test:local -- src/application/javascript/JavaScriptArtifactPathResolution.test.ts src/application/javascript/JavaScriptHtmlBaseResolution.test.ts — 202 passed across 2 test files
  • npm run check:fast — turbo typecheck and lint passed cleanly (2 successful, 0 errors, 0 warnings)
  • npm run test:local -- tests/conformance/readmeConsistency.test.ts — 5 passed

Compatibility, safety, and release

  • Breaking changes or migration steps: none
  • Real Hopper/Ghidra, browser, or OS coverage: platform-independent JavaScript resolution
  • Package or release metadata impact: none
  • Security, privacy, process, or containment review: none

Author readiness

Human owner: @prasad2512

  • I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
  • I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
  • I declare this PR ready for initial maintainer review.

Before merge

  • This PR addresses a concrete problem or an agreed enhancement.
  • Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
  • The PR has one focused outcome and the title follows type(scope): outcome.
  • Related issue is linked, or the reason for not linking one is stated above.
  • Tests cover changed observable behavior and meaningful failure paths.
  • Owning docs, contracts, and generated metadata are updated where needed.
  • User-visible CLI/MCP changes include representative output.
  • I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🔄 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/4838 **Author:** [@prasad2512](https://github.com/prasad2512) **Created:** 10/17/2026 **Status:** ✅ Merged **Merged:** 10/17/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/scope-directory-resolution` --- ### 📝 Commits (1) - [`569e324`](https://github.com/morluto/rea/commit/569e324f760697cfe8e608ea591490566b0ef31a) fix(javascript): admit CommonJS bare scoped package directory resolution ### 📊 Changes **3 files changed** (+175 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `docs/readme/README_fr.md` (+1 -0) 📝 `src/application/javascript/JavaScriptArtifactPathResolution.test.ts` (+167 -0) 📝 `src/application/javascript/JavaScriptArtifactPathResolution.ts` (+7 -3) </details> ### 📄 Description ## Summary Resolves #4632 by admitting CommonJS bare scoped package requests (e.g. `require("@scope")` and `require("@scope/")`) to resolve against locally inventoried `node_modules/@scope` package directories, index files, and package.json main entrypoints, while keeping ESM loader-owned export and invalid-specifier controls authoritative. ## Problem and expected behavior Previously, `parseBarePackageRequest` returned `null` for any specifier starting with `@` that lacked a second segment (`segments[1] === undefined || segments[1] === ""`). This caused `bareModuleCandidate` to unconditionally treat valid CommonJS bare scoped requests like `require("@scope")` and `require("@scope/")` as external/invalid package names before any dependency directory or package metadata lookup occurred, even when `node_modules/@scope/index.js` or `node_modules/@scope/package.json` was present in the inventory. Expected behavior: - CommonJS `require("@scope")` and `require("@scope/")` parse `packageName` as `@scope` and proceed through standard directory / package.json / index.js lookup. - When `package.json` with `exports` is present, `require("@scope")` resolves root exports while `require("@scope/")` respects exports encapsulation (matching Node's `ERR_PACKAGE_PATH_NOT_EXPORTED`). - In ESM (`moduleKind === "import"`), bare `@scope` without a slash remains an invalid module specifier (`ERR_INVALID_MODULE_SPECIFIER`), while `@scope/` continues to be evaluated by loader-owned exports/metadata lookup. - Truly invalid specifiers (`@` and `@/`) remain rejected as external. ## Change and scope 1. In `src/application/javascript/JavaScriptArtifactPathResolution.ts` (`parseBarePackageRequest`): - Reject truly invalid names where `packageName === "@"`. - For scoped specifiers (`specifier.startsWith("@")`), if a package segment exists, join as `${packageName}/${packageSegment}`. - For scope-only specifiers without a second segment: - CommonJS admits them with `packageName = segments[0]`. - ESM rejects `specifier === "@scope"` (without a trailing slash) as invalid module specifier (`return null`). - ESM admits `specifier === "@scope/"` with `packageName = segments[0]` to allow loader-owned exports evaluation. 2. In `src/application/javascript/JavaScriptArtifactPathResolution.test.ts`: - Added `scoped package directory and specifier resolution` suite covering: - CommonJS `require("@scope")` and `require("@scope/")` resolving to `node_modules/@scope/index.js`. - CommonJS `require("@scope-main")` and `require("@scope-main/")` resolving to `package.json` `main: "entry.js"`. - CommonJS `require("@scope")` resolving root exports, while `require("@scope/")` stays external/unmatched against `.` exports. - ESM `import "@scope"` staying external (invalid specifier), while `import "@scope/"` stays external/unmatched. - Controls: `@` and `@/` staying external. ## Contract and boundary impact - Semantic owner and earliest changed stage: `src/application/javascript/JavaScriptArtifactPathResolution.ts` (`parseBarePackageRequest`) - Contribution scope fit and linked maintainer decision: not applicable (bug fix within existing JavaScript path resolution boundary) - CLI and MCP/tool-catalog contract: none - Provider, bridge, target-format, or platform compatibility: all platforms - Evidence, artifact, provenance, or reconstruction contract: preserves exact dependency resolution status and resolved paths - Target selection, authority, upstream behavior, and cleanup details (if applicable): none - Generated metadata (`docs/public/product-catalog.json`), package, or installation impact: none Expected effects: - [ ] Read existing files or captured data. - [ ] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [x] Recover protected code or work around protections. - [x] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. ## Evidence and regression coverage - Tests added or updated: `src/application/javascript/JavaScriptArtifactPathResolution.test.ts` - Base reproduction or other evidence: Verified against Node.js v24.20.0 native `require.resolve` and `import.meta.resolve` behaviors. - User-visible CLI/MCP output (if applicable): none - Remaining proof gaps: none For evidence-bearing changes: - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run test:local -- src/application/javascript/JavaScriptArtifactPathResolution.test.ts src/application/javascript/JavaScriptHtmlBaseResolution.test.ts` — 202 passed across 2 test files - `npm run check:fast` — turbo typecheck and lint passed cleanly (2 successful, 0 errors, 0 warnings) - `npm run test:local -- tests/conformance/readmeConsistency.test.ts` — 5 passed ## Compatibility, safety, and release - Breaking changes or migration steps: none - Real Hopper/Ghidra, browser, or OS coverage: platform-independent JavaScript resolution - Package or release metadata impact: none - Security, privacy, process, or containment review: none ## Author readiness Human owner: @prasad2512 - [x] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [x] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [x] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
bsakaguchi 2026-10-31 01:14:27 +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#6436
No description provided.