Fix elysia standard-mode compression via the documented mapResponse pattern - #1089
Open
MDA2AV wants to merge 2 commits into
Open
Fix elysia standard-mode compression via the documented mapResponse pattern#1089MDA2AV wants to merge 2 commits into
MDA2AV wants to merge 2 commits into
Conversation
Owner
Author
|
/benchmark -f elysia --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
|
|
…rn (#1075) The entry hand-rolled Accept-Encoding negotiation in /json/:count with Bun.gzipSync, and its br branch shipped Bun.deflateSync bytes labeled "content-encoding: br" (latent because the branch compared the whole header to "br", so "gzip, br" never reached it). No compression plugin works on elysia 1.4: elysia-compress imports mapResponse from elysia's root export, removed in 1.2.6 (vermaysha/elysia-compress#149, repo archived Nov 2025), and every fork carries the same import. The framework's documented compression mechanism is the mapResponse lifecycle hook, so this follows the official docs example (elysiajs.com/essential/life-cycle) extended with real per-request negotiation: - picks the first acceptable encoding in the client's own order (br or gzip, q=0 honoured) via node:zlib at default settings — bare "Accept-Encoding: br" now returns genuine brotli - 1024-byte threshold, matching the express/fastify middleware defaults - no caches, no pre-compressed bodies; ready-made Responses and files pass through untouched (static serving identical to before) - maps Elysia custom-status objects explicitly: with a mapResponse hook registered, letting a status() object fall through yields an empty 200, which broke the static 404 check until handled validate.sh elysia: 31 passed, 0 failed. Bare-br verified by brotli-decompressing /json/50?m=3 to the full correct schema. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
MDA2AV
force-pushed
the
fix/elysia-standard-compression
branch
from
August 12, 2026 13:26
55aeaa9 to
694f87f
Compare
Owner
Author
|
/benchmark -f elysia --save |
Contributor
|
👋 Benchmark request received. A collaborator will review and approve the run. |
Contributor
Benchmark ResultsFramework:
Full log |
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.
Description
Closes #1075 — the elysia entry hand-rolled compression negotiation in
/json/:countwhile markedmode: standard, and itsbrbranch shipped deflate bytes labeledcontent-encoding: br(latent: the branch compared the whole header to"br", so validation'sgzip, brnever reached it).Why not a compression plugin
The plugin route (the issue's first preference) is a dead end on elysia 1.4 — verified by building, not just reading:
elysia-compressfails to compile: it importsmapResponsefrom elysia's root export, removed in elysia 1.2.6 (vermaysha/elysia-compress#149); the repo was archived Nov 2025. Its default 24 h compressed-response cache would also collide with the json-comp rule's "no pre-compressed caches" clause.@labzzhq/compressor(fork) carries the identical broken import; the remaining plugins are 2+ years stale.Elysia's own docs prescribe compression via the
mapResponselifecycle hook (essential/life-cycle) — that is the framework's built-in compression mechanism, so this PR implements the docs pattern extended with real negotiation, keeping the entrystandard:brorgzip,q=0honoured),node:zlibat default settings — a bareAccept-Encoding: brnow returns genuine brotliResponses/files pass through untouched, so static serving is byte-identical to beforeTwo Elysia warts the hook must handle (worth knowing for future TS entries)
headersis absent from the hook context on the error path — an unguarded read turns every 404 into a 500.mapResponseregistered, letting an Elysia custom-status object (status()returns, plugin 404s) fall through swallows the status into an empty 200; the hook mapscode-carrying objects explicitly. Without this,GET /static/nonexistent.txtbroke.Verification
./scripts/validate.sh elysia: 31 passed, 0 failed (json-comp:Content-Encoding: gzip, compressed schema, per-request negotiation; static: 20 sizes + 404 intact)brcheck (the case validation doesn't exercise):curl -H 'Accept-Encoding: br' /json/50?m=3decompresses withzlib.brotliDecompressSyncto the full correct 50-item schema with correct totalsThanks @nigrosimone for the report.