[PR #4315] [MERGED] fix(package): parse tar listings without platform line endings #6164

New issue

Closed

opened 2026-10-31 01:12:21 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:12:21 +00:00

Owner

📋 Pull Request Information

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

Base: main ← Head: fix/package-tar-crlf-listing

📝 Commits (2)

032f3ec fix(package): parse tar listings without platform line endings
6fdc748 Merge origin/main into fix/package-tar-crlf-listing

📊 Changes

4 files changed (+82 additions, -4 deletions)

View changed files

➕ scripts/lib/verify-package-listing.d.mts (+2 -0)
➕ scripts/lib/verify-package-listing.mjs (+15 -0)
📝 scripts/verify-package-pack.mjs (+4 -4)
➕ tests/conformance/package/packedTarListing.test.ts (+61 -0)

📄 Description

Summary

verify-package-pack.mjs parsed tar -tf output with stdout.split("\n"). Windows ships two tar implementations, and C:\Windows\System32\tar.exe (bsdtar) terminates every listed member with CRLF, so each non-final member kept a trailing \r. verifyPackedBridge compares member identities exactly (packedFiles.includes(path)), so a real Windows lane reported package omitted package/bridge/hopper_bridge.py although the tarball ships that member.

Fixes #4128

Change and scope

Adds scripts/lib/verify-package-listing.mjs (+ its .d.mts, matching the repo convention for script modules imported from TypeScript) with parseTarListing, which splits on /\r?\n/ and drops the empty member left by the trailing line ending. Member strings are preserved beyond their line ending.
verifyPackagePack now parses the listing through it, so every consumer compares bare member names.
Line endings are normalized once, at the listing owner, as the issue asks. verifyPackagePack is the only tar listing producer in the package verifiers, so no other parse site needs the same treatment; the two startsWith prefix checks in that file never matched a line ending and keep their behavior.

Out of scope: the unrelated stdout.split("\n") call sites in browser, Ghidra and Hopper verifier scripts, which parse source lines or process output rather than tar listings.

Verification

Real Windows 11, listing containing package/bridge/hopper_bridge.py:

tar	listing line endings	previous `split("\n")`	`parseTarListing`
Git for Windows GNU tar	LF	`true`	`true`
`C:\Windows\System32\tar.exe`	CRLF	`false` (bug reproduced)	`true`

New conformance test tests/conformance/package/packedTarListing.test.ts (5 tests, vitest run passes): CRLF and LF listings both yield exact bridge identities, the trailing line ending no longer produces an empty member, member strings keep embedded spaces, and a regression guard pins the previous parse's failure.

Also run locally: tsc --noEmit clean, oxfmt --check clean on the changed files, turbo run lint successful.

Not run: the full scripts/verify-packaged-wasm-artifact.mjs lane, which needs a packaged npm artifact and a python3 on PATH for the bridge AST check.

_{🔄 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/4315 **Author:** [@KimChow](https://github.com/KimChow) **Created:** 10/16/2026 **Status:** ✅ Merged **Merged:** 10/16/2026 **Merged by:** [@morluto](https://github.com/morluto) **Base:** `main` ← **Head:** `fix/package-tar-crlf-listing` --- ### 📝 Commits (2) - [`032f3ec`](https://github.com/morluto/rea/commit/032f3ec84e208bd8fd8412c099166397a9cf4677) fix(package): parse tar listings without platform line endings - [`6fdc748`](https://github.com/morluto/rea/commit/6fdc748223c16e065d3edf39d8481b345418dd68) Merge origin/main into fix/package-tar-crlf-listing ### 📊 Changes **4 files changed** (+82 additions, -4 deletions) <details> <summary>View changed files</summary> ➕ `scripts/lib/verify-package-listing.d.mts` (+2 -0) ➕ `scripts/lib/verify-package-listing.mjs` (+15 -0) 📝 `scripts/verify-package-pack.mjs` (+4 -4) ➕ `tests/conformance/package/packedTarListing.test.ts` (+61 -0) </details> ### 📄 Description ## Summary `verify-package-pack.mjs` parsed `tar -tf` output with `stdout.split("\n")`. Windows ships two tar implementations, and `C:\Windows\System32\tar.exe` (bsdtar) terminates every listed member with CRLF, so each non-final member kept a trailing `\r`. `verifyPackedBridge` compares member identities exactly (`packedFiles.includes(path)`), so a real Windows lane reported `package omitted package/bridge/hopper_bridge.py` although the tarball ships that member. Fixes #4128 ## Change and scope - Adds `scripts/lib/verify-package-listing.mjs` (+ its `.d.mts`, matching the repo convention for script modules imported from TypeScript) with `parseTarListing`, which splits on `/\r?\n/` and drops the empty member left by the trailing line ending. Member strings are preserved beyond their line ending. - `verifyPackagePack` now parses the listing through it, so every consumer compares bare member names. - Line endings are normalized once, at the listing owner, as the issue asks. `verifyPackagePack` is the only tar listing producer in the package verifiers, so no other parse site needs the same treatment; the two `startsWith` prefix checks in that file never matched a line ending and keep their behavior. Out of scope: the unrelated `stdout.split("\n")` call sites in browser, Ghidra and Hopper verifier scripts, which parse source lines or process output rather than tar listings. ## Verification Real Windows 11, listing containing `package/bridge/hopper_bridge.py`: | tar | listing line endings | previous `split("\n")` | `parseTarListing` | | --- | --- | --- | --- | | Git for Windows GNU tar | LF | `true` | `true` | | `C:\Windows\System32\tar.exe` | CRLF | **`false`** (bug reproduced) | `true` | New conformance test `tests/conformance/package/packedTarListing.test.ts` (5 tests, `vitest run` passes): CRLF and LF listings both yield exact bridge identities, the trailing line ending no longer produces an empty member, member strings keep embedded spaces, and a regression guard pins the previous parse's failure. Also run locally: `tsc --noEmit` clean, `oxfmt --check` clean on the changed files, `turbo run lint` successful. Not run: the full `scripts/verify-packaged-wasm-artifact.mjs` lane, which needs a packaged npm artifact and a `python3` on PATH for the bridge AST check. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:12:21 +00:00