build: use @electron-internal/extract-zip

[claude]

Requested by David Sanders · Slack thread

This swaps our direct extract-zip dependency for @electron-internal/extract-zip (1.0.5), the Electron-maintained native drop-in replacement. It has the same default-export extract(zipPath, { dir }) signature, so the two call sites in e auto-roll and the dist download path only change their import. It also drops extract-zip and its yauzl-based dependency tree from the lockfile, since nothing else depended on it. Build, lint, and tests pass apart from the existing e-init test that can't bootstrap depot_tools in the sandbox (it fails on main too), and in a manual check the new package extracted a zip with nested dirs, exec bits, and framework-style symlinks identically to extract-zip. No .yarnrc.yml change was needed because 1.0.5 is older than the age gate.

🤖 Generated with Claude Code

https://claude.ai/code/session_016v1gicQBW7wMJeDkqcScc6

---

Generated by Claude Code

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​electron-internal/​extract-zip@​1.0.5

View full report

[claude]

Looks good, straightforward dependency swap. Checked that import sites in src/e-auto-roll.ts and src/utils/download-dist.ts, package.json, and yarn.lock are all consistently updated with no leftover references to the old extract-zip package, and the new package resolves cleanly in the lockfile with the same call signature.

Extended reasoning...

The change swaps a direct npm dependency (extract-zip) for an internal fork (@ electron-internal/extract-zip) across package.json, two import sites, a comment, and the lockfile. It touches no auth, crypto, or permission logic — only a build-time dependency and its two call sites, both of which use the identical default-export signature. The diff is small, mechanical, and self-consistent (no leftover references to the old package name), and no reviewer raised an outstanding objection in the timeline (one approval from dsanders11, no CHANGES_REQUESTED). The one ruled-out item (missing @ electron-internal/* entry in npmPreapprovedPackages) is a future-maintenance note, not a defect in this PR, since 1.0.5 already clears the age gate per the author's description and the lockfile confirms.