solid-start

PR Checklist Please check if your PR fulfills the following requirements: [x] Addresses an existing open issue: fixes #2356 [x] Tests for the changes have been added (for bug fixes / features) What is the current behavior? creates its filter when the plugin is created, with relative default patterns and no option, so they are resolved against . The plugin names each module relative to as well. On Windows a working directory entered through a junction or symlink keeps that path, while Vite resolves every module id, and since 8.2 also , to the real path. Then: the filter matches no module, so no function is compiled: its body ends up in the client bundle, and a build whose server functions import fails with ; the of a lazily loaded route component matches no client manifest key, so its CSS is missing from the server-rendered HTML. #2356 has the steps. What is the new behavior? The filter is created in , with as the base for relative patterns. derives from the way Vite derives its manifest keys (), and the dev style lookup resolves that id against the root instead of . Since Vite 8.2 resolves the root like every module id (to the real path; with , since 8.2.2 the root keeps the link path as the ids do), this works when the working directory is a junction or symlink to the project; when it is the root itself, nothing changes. Relative patterns passed through the option now resolve against the root too. The tests make differ from Vite's root, which is what a junction gives on Windows, so they run on any OS: (new): a module under the root's is compiled, one outside it is left alone, and a relative custom resolves against the root. : is relative to the root (without the change it is ); the existing cases pass the root through the plugin context. (new): the dev style lookup finds the styles of a root-relative id. Without the change, four of the five new tests fail (the guard for a module outside passes either way), and the 266 existing tests pass. A changeset is included. Other information Checked on Windows (Node 26.10.0, Vite 8.3.4) with the basic template and the route from #2356, plus a route whose server function imports nothing. With 2.0.6, the build through a junction fails, whether the junction is on the project's drive or on another; without the server-only import it builds, but that function's body is in the client bundle. With this branch packed and installed, both junction builds pass, the client chunks hold server references instead of function bodies, and the server-rendered index page links the same stylesheets as a build from the real path. Not covered here: also takes as its root (app entry, alias, file routers), and relative patterns are resolved against it as well. Through a junction, the alias treats every app module as another package's, so in a page that imports does not finish rendering (the template's index page: the request was still open after 20 s; with a relative import it renders). The file routers match the real paths in Vite's watcher events against a glob built on the link path, so route changes are probably missed in dev (from reading the code, not tried). The template still builds only because Rolldown applies its tsconfig to ; without that mapping the build fails as well. runs before Vite resolves its root, so moving these to the root means restructuring it; I left that for a separate change. With Vite before 8.2 the root keeps the link path while module ids do not, so the filter part of this change does not help there (this repository's lockfile still resolves Vite 8.1.5); the ids follow Vite's own key formula either way.

Duplicates [x] I have searched the existing issues Latest version [x] I have tested the latest version Current behavior 😯 On Windows, when the working directory reaches the project through a directory junction or a symbolic link, no function is compiled. A build whose server functions import server-only code such as fails: Without such an import the build succeeds, but the body of the server function is in the client bundle. The same project builds correctly when the working directory is its real path. The server functions plugin creates its filter with and no option, so the relative patterns are resolved against . On Windows the working directory keeps the path it was entered through, while Vite resolves every module id, and since 8.2 also , to the real path. The filter then matches no module. Linux and macOS report the real path from , so they are not affected. The plugin derives from in the same way. Once the filter matches, a build through a junction succeeds, but the ids of lazily loaded route components match no client manifest key, so their CSS is missing from the server-rendered HTML (in the basic template, the index route's CSS). Expected behavior 🤔 Building the project through a junction compiles its server functions and puts the route CSS in the server-rendered HTML, as a build through its real path does. Steps to reproduce 🕹 Steps (Windows, ): 1. , then and . 2. Add : 3. succeeds. 4. Create a junction to the project and build through it: , then and . The build fails with the error above. The junction is on the same drive as the project, so this is not Vite's known problem with links across drives; a junction to another drive fails the same way. A pull request follows that fixes the filter and , with tests that reproduce both on any OS by making differ from Vite's root. Context 🔦 I open my checkouts through a junction from another drive, and the error suggests a mistake in the application code rather than a path problem, so the cause was hard to find. Your environment 🌎

Duplicates [x] I have searched the existing issues Latest version [x] I have tested the latest version Current behavior 😯 npm run dev causes HMR error for notes template Expected behavior 🤔 no error Steps to reproduce 🕹 Steps: 1. npm init solid@latest 2. select TypeScript, notes 3. npm i 3. npm run dev, open browser 4. modify src/routes/(home).tsx, e.g. add extra "!" 5. observe browser state Context 🔦 _No response_ Your environment 🌎