fix(release): drop extension test files from the packaged build - #62
Merged
Conversation
stage() copies extensions/ai-sidebar wholesale with `cp -RL`, so the two vitest files next to the extension sources ship inside every download: moshpit.test.js, and now moshpit-drift.test.js. Chrome never loads them — neither is in manifest.json and nothing manifest.json does load imports them — but moshpit-drift.test.js does `import * as pkg from '@moshcoder/moshpit-resolve'`, a devDependency that cannot resolve from an unbundled extension, so it is unresolvable dead code in a shipped artifact. Prune them after the copy. Staged extension goes 284K -> 268K. Note: release.yml does the same wholesale copy on the Windows path (Copy-Item -Recurse), so it needs the matching prune to fully close this. That change is not in this PR — see the PR description. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
vu1nz Security Review0 finding(s) in PR #? No security issues found. |
ralyodio
marked this pull request as ready for review
August 1, 2026 05:59
ralyodio
added a commit
that referenced
this pull request
Aug 1, 2026
#62 pruned them from build-release.sh, which covers linux/macos/deb/rpm/ AppImage. The Windows job stages separately with Copy-Item -Recurse and kept shipping them: v3.8.9's tronbrowser-win-x64.zip contains moshpit.test.js (12077B) and moshpit-drift.test.js (4106B). Mirror the prune in the pwsh path so every platform matches. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
ralyodio
added a commit
that referenced
this pull request
Aug 1, 2026
#65) * fix(release): drop extension test files from the Windows zip too #62 pruned them from build-release.sh, which covers linux/macos/deb/rpm/ AppImage. The Windows job stages separately with Copy-Item -Recurse and kept shipping them: v3.8.9's tronbrowser-win-x64.zip contains moshpit.test.js (12077B) and moshpit-drift.test.js (4106B). Mirror the prune in the pwsh path so every platform matches. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(store): stamp our update_url into the .crx, so installs can update Chromium polls the update_url baked into the installed manifest — it never consults the feed the store advertises on the listing page. Most publishers omit it (it points at us, and they write their manifest long before they list here), so a store install pinned itself to whatever version it was installed at and never moved again, while the store served a correct updates.xml that nothing ever asked for. CoinPay Wallet is the live case: the store, its gupdate feed and the packed .crx are all at 0.9.2, but the shipped manifest has no update_url, so every existing install sits on the version it was first given. The .crx is packed on demand and we already know the feed URL, so set it there, before signing (the CRX3 signature covers the zip bytes). Overwriting a publisher's own update_url is deliberate: the id comes from the store's signing key, and only our feed can serve an update Chromium accepts for it. Verified against the real published 0.9.2 bundle: all 13 files stay byte-identical, only the empty directory entries drop (Chromium recreates those from the paths), and the resulting .crx carries the feed URL. Note this cannot rescue already-installed copies — they have no update_url to poll, so they need one manual reinstall to get onto the channel. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
stage()inapps/desktop/scripts/build-release.shcopies the extension wholesale:There's no pruning afterwards, so the vitest files that live next to the extension sources ship inside every download —
moshpit.test.jstoday, andmoshpit-drift.test.jsas of #60.Chrome never executes them: neither is listed in
manifest.json, and nothingmanifest.jsondoes load imports them. Butmoshpit-drift.test.jscontainswhich is a devDependency — by the test's own reasoning it can never resolve from an unbundled extension. So we're shipping unresolvable dead code in a release artifact.
Change
One
find -deleteafter the copy. Staged extension: 284K → 268K.Verified: syntax clean (
bash -n), both test files removed,manifest.jsonand the other 31 entries untouched.release.ymldoes the same wholesale copy on the Windows path, so Windows builds keep shipping the test files until it gets the matching prune. I couldn't include it here — my token lacks theworkflowscope, so any push touching.github/workflows/is rejected.Apply this on top before tagging a release:
Copy-Item -Recurse apps/desktop/extensions/ai-sidebar "$stage/extensions/ai-sidebar" + Get-ChildItem "$stage/extensions/ai-sidebar" -Filter *.test.js -Recurse | Remove-Item -Force Copy-Item LICENSE "$stage/LICENSE"Release note
release.ymlrunsscripts/set-version.mjson the runner from the tag name, so no version-bump commit is needed — taggingv3.8.9is sufficient once this is merged. Tagging before merging would ship exactly the thing this fixes.🤖 Generated with Claude Code