Repository navigation
fix(void): ignore type-only exports when detecting route methods and SSR render - #221
Merged
Merged
Conversation
❌ Deploy Preview for staging-void-cloud failed.
|
hyfdev
marked this pull request as ready for review
June 18, 2026 13:01
…SSR render
Both the route HTTP-method scanner (detect-exports) and the SSR entry
validator walked named-export specifiers without checking exportKind, so
a type-only export was mistaken for a runtime value. `export type { GET }`
or `export { type GET }` in a route file made the scanner register a GET
route whose handler is undefined at runtime (a 500 instead of a 404/405);
`export type { render }` made an SSR entry pass validation with no real
render function.
Skip exports whose exportKind is "type" (both the statement-level
`export type { ... }` and inline `export { type X }` specifiers) in both
detectors. Add exportKind to the shared AST specifier/declaration types.
hyfdev
force-pushed
the
fix/ignore-type-only-exports
branch
from
June 18, 2026 16:09
e11c5c1 to
7d65d8e
Compare
Brooooooklyn
approved these changes
Jun 30, 2026
cpojer
pushed a commit
that referenced
this pull request
Sep 11, 2026
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.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
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.
Route files and SSR entries that re-export a handler type no longer register a phantom runtime route or pass entry validation — the scanners now ignore type-only exports.
The bug
Two AST walkers that detect runtime exports never checked
exportKind:detectHttpExports(router/detect-exports.ts) —export type { GET }orexport { type GET }in a route file made the scanner register aGETroute. The export is erased at build time, so at request time the handler isundefined→ a 500 instead of a 404/405.validateServerRenderExport(ssr/entry.ts) —export type { render }made an SSR entry pass the "has a render export" check with no real render function.Expected-correct behavior
A type-only export carries no runtime value, so it must not be treated as a route handler / render export. Verified against void's parser (
vite parseSync):export type { X }carriesexportKind: "type"at the statement level;export { type X }carries it at the specifier level — so both levels must be guarded.Minimal repro
A route file
routes/hello.tscontainingtype GET = () => Response; export type { GET };produceddetectHttpExports() === ['GET'](should be[]).The fix
Skip exports whose
exportKind === 'type'— at both the statement level (export type { ... }) and the specifier level (export { type X }) — in both detectors. AddexportKindto the shared AST specifier/declaration types. (As a bonus this also stopsexport declare const GETambient declarations being mistaken for routes.)Tests
Regression tests added: 2 in
detect-exports.test.ts(statement-level type export →[]; inlineexport { POST, type GET }→['POST']) and 1 inssr-entry.test.ts(export type { render }→ throws the missing-render error). All fail onorigin/mainand pass after. Local gate: the two test files 19/19; full--project unitzero-collateral vs a cleanorigin/mainbaseline (identical pre-existing adapter/init-migration failures, unrelated);packages/voidtypecheck + lint + fmt clean.I checked that these are the only two sites that infer a runtime export from named-export specifiers (the page
loader/actions, websocket, and queue scanners use regexes/default-exports that are structurally immune), so the bug class is fully covered.Prepared with AI assistance.