filesystem-routing

When route metadata is reexported from a page module, selecting only from the wrapper still loads the page's component dependency and CSS. Selecting directly from the page isolates them. I'd like to clarify the intended boundary before proposing a production change. My consumer loads route metadata in an isolated server runner to generate static artifacts. It currently rewrites named reexport sources to pass the selected names through. Removing that workaround would simplify the integration, but unconditional propagation has an identity problem. Reproduction Executable fixture and assertions, based on . The first test run characterizes the current behavior and passes all 14 cases. The second asks for transitive isolation and fails in three cases: dev SSR, client build and SSR build. The relevant pattern is: The selected wrapper retains . The source module is loaded without a pick. The fixture gives the component dependency an observable side effect and sets , so the build comparison does not depend on ordinary dead-code elimination. Why a source rewrite is insufficient A test-only rewrite to isolates the component dependency. When another consumer imports the full page, however, it creates a second instance: This happens in dev SSR and in the executed SSR bundle. It is related to the module-identity concern in #16 and #17. This fixture uses an observable initializer; it does not reproduce or the HTTP 405 path itself. Moving metadata into a separate module works with the current API: it avoids loading the component dependency and preserves the same metadata instance. That adds an explicit module boundary for consumers to maintain. Contract question Should picks remain module-local, with separate metadata modules as the supported pattern, or would a narrowly scoped selection mechanism for isolated loading graphs fit this package? Any transitive behavior would need to define module identity, aliases, multiple selected names, existing queries, explicit side effects and . The reproduction also confirms that stays unchanged; expanding its behavior is outside this proposal. Validated with Node 24.15.0, Vite 6.4.3 and Vitest 2.1.9. The full suite passes 127 tests; TypeScript, build and formatting checks pass. Vite 7/8, HMR and browser execution were not tested. The linked commit contains only the reproduction tests.

Would a helper fit the neutral manifest API? My Knip config uses to find page and HTTP handler modules. Extracting their source paths currently needs a type guard and a loop over the reserved keys because the manifest's index signature is . With a typed helper, that part becomes: The proposed result is an array of pairs. It keeps and keys, order, ref identity and separate refs for different picked exports of the same source. It skips null/undefined refs and only visits direct properties of a neutral entry. I have an implementation ready in the linked branch, reused by the Vite build-input and type-generation paths. Build and all 116 tests pass. In my app, it produces the same refs as the existing extraction for all three route directories (9, 1 and 26 modules). The immediate benefit is removing two small helpers from tooling. That is a modest gain, so I'd like your view on whether it warrants a public API before opening another PR. Implementation: https://github.com/everton-dgn/filesystem-routing/commit/cca30bd3a6b40467145db12c4cde876420f90bbe

Summary answers with the module's export (). But the "declining" contract, where a that returns falls through to the page render (or gives a 404 for a handler-only module), only applies when . For a answered by that same , a decline throws , and the app's error handling turns that into a 500. So a page route with a conditional (the usual canonical-redirect pattern) returns to and to . RFC 9110 §9.3.2 says HEAD is identical to GET except the server does not send content. Link checkers, uptime monitors, CDNs and crawlers send , so this shows up as spurious 500s. Where (0.4.0, same code on at 90a19ee) : https://github.com/solidjs/filesystem-routing/blob/90a19eeb5c58becb0b5d599527c99452eab6f1c5/src/api.ts#L199-L213 The docblock above it says " falls back to the handler" and "A handler returning declines the request, allowed for only". These two rules contradict each other when HEAD is served by GET. The existing tests cover "serves HEAD through the GET handler" (a GET that answers) and "throws when a non-GET handler declines" (POST), but not a HEAD served by a declining GET. Repro The same thing at unit level, next to the existing tests in : Suggested fix Treat a decline on exactly like one on : continues the chain with the original request, so the page renders as it would for , and the server or adapter drops the body. A narrower version would allow the decline only when and keep throwing for an explicit export that returns nothing. I don't see a reason to treat an explicit export differently, though: falling through to the page is the HEAD equivalent of what that page does for GET. The docblock line would change to "allowed for and only". Workaround We currently wrap the dispatcher and give it a clone of a request (), so a declining falls through as it does for , and the original continues down the chain. I'm happy to send a PR with the fix and the test above if this direction sounds right.