[PR #582] [MERGED] fix(artifacts): expand nested ASARs on Windows #2083

New issue

Closed

opened 2026-10-16 21:14:02 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-16 21:14:02 +00:00

Owner

📋 Pull Request Information

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

Base: main ← Head: fix/windows-nested-asar

📝 Commits (1)

dc1a614 fix(artifacts): expand nested ASARs on Windows

📊 Changes

2 files changed (+6 additions, -4 deletions)

View changed files

📝 src/application/ArtifactInventory/scanReader.ts (+3 -1)
📝 tests/boundary/filesystem/asarInventoryFreshness.test.ts (+3 -3)

📄 Description

Summary

Expand ASARs inside directory inputs on Windows. The inventory reader previously recognized filesystem-backed ASARs only when their adapter keys started with /, so Windows bundle inventory retained the archive as an opaque file and JavaScript reconstruction found no nested sources.

Use the host's absolute-path predicate, matching the JavaScript reconstruction reader. Update the two direct @electron/asar.listPackage cache assertions to expect the documented host separator.

Evidence and regression coverage

The native Windows lane added in #581 exposed four failures: two actual nested archive failures and two POSIX-specific provider-path assertions. Standalone Windows ASAR reads and the suffix-directory regression already passed.

The existing packed-ASAR tests exercise changed archive inventory for directory and standalone inputs, full nested JavaScript source reconstruction, and actual provider cache behavior. The Windows lane retains all these cases.

Validation

13 focused ASAR inventory and JavaScript reconstruction tests passed on macOS arm64.
npm run check:fast, formatting, and staged diff checks passed.
Native Windows verification runs in the existing CI lane; no local Windows result is claimed.
No real Hopper/Ghidra verification performed; these providers and tool schemas are unchanged.

Follow-up to #581 and #570. No added filesystem scopes, permissions, or dependencies.

_{🔄 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/582 **Author:** [@morluto](https://github.com/morluto) **Created:** 10/5/2026 **Status:** ✅ Merged **Merged:** 10/5/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/windows-nested-asar` --- ### 📝 Commits (1) - [`dc1a614`](https://github.com/morluto/rea/commit/dc1a61419f4dca71250c77e255519c7ee70d7d53) fix(artifacts): expand nested ASARs on Windows ### 📊 Changes **2 files changed** (+6 additions, -4 deletions) <details> <summary>View changed files</summary> 📝 `src/application/ArtifactInventory/scanReader.ts` (+3 -1) 📝 `tests/boundary/filesystem/asarInventoryFreshness.test.ts` (+3 -3) </details> ### 📄 Description ## Summary Expand ASARs inside directory inputs on Windows. The inventory reader previously recognized filesystem-backed ASARs only when their adapter keys started with `/`, so Windows bundle inventory retained the archive as an opaque file and JavaScript reconstruction found no nested sources. Use the host's absolute-path predicate, matching the JavaScript reconstruction reader. Update the two direct `@electron/asar.listPackage` cache assertions to expect the documented host separator. ## Evidence and regression coverage The native Windows lane added in #581 exposed four failures: two actual nested archive failures and two POSIX-specific provider-path assertions. Standalone Windows ASAR reads and the suffix-directory regression already passed. The existing packed-ASAR tests exercise changed archive inventory for directory and standalone inputs, full nested JavaScript source reconstruction, and actual provider cache behavior. The Windows lane retains all these cases. ## Validation - 13 focused ASAR inventory and JavaScript reconstruction tests passed on macOS arm64. - `npm run check:fast`, formatting, and staged diff checks passed. - Native Windows verification runs in the existing CI lane; no local Windows result is claimed. - No real Hopper/Ghidra verification performed; these providers and tool schemas are unchanged. Follow-up to #581 and #570. No added filesystem scopes, permissions, or dependencies. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-16 21:14:02 +00:00