chore: strip symbols from release binary#1049
Merged
Merged
Conversation
camc314
approved these changes
Jul 3, 2026
Contributor
Merge activity
|
## What Add `-ldflags="-s -w"` to the `build` recipe (both `[unix]` and `[windows]`), stripping the DWARF debug info (`-w`) and the symbol table (`-s`) from the compiled binary. The release workflow builds via `just build`, so all six published per-platform npm binaries pick this up automatically — no change needed in `release.yml`. ## Binary size impact Measured on a local `darwin/arm64` build. The ~27% raw / ~45% compressed proportion holds across all six release targets. | | Raw binary | Gzipped (npm tarball users download) | |---|---|---| | Before | 29.7 MB | 13.1 MB | | After | 21.8 MB | 7.2 MB | | **Saved** | **7.9 MB (26.6%)** | **5.9 MB (44.9%)** | The compressed saving is *proportionally larger* than the raw saving because DWARF debug data compresses poorly, so removing it takes out a disproportionate share of the actual download. npm installs only the single package matching a user's OS/arch (via `os`/`cpu` + `optionalDependencies`), so each user's download drops ~5.9 MB (~45%) and their `node_modules` footprint drops ~7.9 MB. ## Behavior No functional or runtime change — `-s -w` removes metadata only, never code: - Same lint results, same output, same speed, same exit codes. - Panic stack traces keep full function names and line numbers (Go's `gopclntab` is not stripped). - pprof profiling still symbolicates; `go version -m ./tsgolint` build info is preserved. The one capability lost is attaching Delve/gdb to the shipped binary for source-level debugging (that needs the DWARF info removed by `-w`) — which is not something an end user of a linter ever does. Contributors who need it can still build an unstripped binary directly with plain `go build`.
graphite-app
Bot
force-pushed
the
chore/strip-release-binary
branch
from
f8b732f to
3a2a87e
Compare
Boshen
force-pushed
the
chore/strip-release-binary
branch
from
9621f38 to
3a2a87e
Compare
graphite-app Bot
pushed a commit
that referenced
this pull request
Jul 3, 2026
## What Add `-trimpath` to the `build` recipe (both `[unix]` and `[windows]`), alongside the existing `-ldflags="-s -w"` from #1049. `-trimpath` replaces absolute filesystem paths baked into the binary — the local build directory and the Go module cache — with clean module-relative paths. ## Why — hygiene, not size - **Reproducible builds.** The output stops depending on *where* it was built, so the same commit built on different machines/paths produces an identical binary. - **No leaked local paths.** Without it, panic stack traces and build metadata embed the builder's absolute paths (e.g. `/Users/<name>/.../typescript-go/internal/checker/checker.go`). `-trimpath` reduces those to `github.com/microsoft/typescript-go@.../internal/checker/checker.go`. ## Size impact — negligible (measured on the merged `-s -w` baseline) | metric | `-s -w` | `+ -trimpath` | delta | |---|---|---|---| | raw binary | 21.79 MB | 21.74 MB | −49.5 KB (0.23%) | | gzipped / npm download | 7.19 MB | 7.19 MB | −2.1 KB (0.03%) | | `__gopclntab` | 6601.6 KB | 6563.8 KB | −37.8 KB (0.57%) | The ~50 KB raw saving is incidental (trimmed path strings living in `gopclntab`); the download users actually fetch moves ~2 KB, because those repetitive path prefixes were already compressing away under npm's gzip. This is a build-hygiene change, not a size optimization. ## Behavior No runtime change. Panic traces still show full function names and `file:line` — only the path *prefix* changes (module-relative instead of absolute).
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
2 participants
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
Add
-ldflags="-s -w"to thebuildrecipe (both[unix]and[windows]), stripping the DWARF debug info (-w) and the symbol table (-s) from the compiled binary. The release workflow builds viajust build, so all six published per-platform npm binaries pick this up automatically — no change needed inrelease.yml.Binary size impact
Measured on a local
darwin/arm64build. The ~27% raw / ~45% compressed proportion holds across all six release targets.The compressed saving is proportionally larger than the raw saving because DWARF debug data compresses poorly, so removing it takes out a disproportionate share of the actual download.
npm installs only the single package matching a user's OS/arch (via
os/cpu+optionalDependencies), so each user's download drops ~5.9 MB (~45%) and theirnode_modulesfootprint drops ~7.9 MB.Behavior
No functional or runtime change —
-s -wremoves metadata only, never code:gopclntabis not stripped).go version -m ./tsgolintbuild info is preserved.The one capability lost is attaching Delve/gdb to the shipped binary for source-level debugging (that needs the DWARF info removed by
-w) — which is not something an end user of a linter ever does. Contributors who need it can still build an unstripped binary directly with plaingo build.