fix: make illegal server-only import errors actually useful - #14155
Conversation
🦋 Changeset detectedLatest commit: 21650f4 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
I actually think we can get the import chain in development too, by inspecting the dev server's module graph. Tinkering on that locally |
| normalized === '$env/static/private' || | ||
| normalized === '$env/dynamic/private' || | ||
| normalized === '$app/server' || | ||
| normalized.startsWith('$lib/server') || |
There was a problem hiding this comment.
I wonder if we can easily change this to only match $lib/server/ directories or $lib/server.* files to fix #14069 but I guess that can be its own PR after this one
There was a problem hiding this comment.
ah yeah this should really just add a trailing slash. We don't state anywhere that $lib/server.ts should be considered a server-only module — just this:
You can make your own modules server-only in two ways:
- adding
.serverto the filename, e.g.secrets.server.js- placing them in
$lib/server, e.g.$lib/server/secrets.js
Unfortunately we do currently regard $lib/server.ts as server-only, so the simple fix would be a breaking change. I think we should fix that in SvelteKit 3 and warn on it in the meantime. Will do it as a separate PR
There was a problem hiding this comment.
Actually I've changed my mind. If we think it's okay to fix #14069 in a patch release then the same is true of $lib/server.ts. Just gonna update .startsWith('$lib/server') to .startsWith('$lib/server/')
…#14155) * hide useless stack * defer to graph_analysis in build, so the more useful error appears * tweak error message * various fixes * prevent double-logging * tidy up a lil * changeset * unify * tidy up * tweak * unused * simplify, update tests * simplify * simplify/fix * tweak * fix tests * try this * while we're here * getting closer * ahhh i think this is it * last bit * Update packages/kit/src/exports/vite/utils.js * Update packages/kit/test/apps/dev-only/test/test.js * test for indirect import
Addresses part of #15461 `vite-plugin-sveltekit-guard` builds its `import_map` in every environment, but the map is only read in the `load` hook, which bails for non-client consumers before touching it. On the svelte.dev build that makes 69% of the guard's `resolveId` calls (3,987 of 5,778) dead work, and the guard was the top entry in dominikg's `PLUGIN_TIMINGS` report in #13756. This adds the same consumer bail to `resolveId`. The error chains from #14155 are unaffected because the client environment collects its own edges. Measured on the svelte.dev build with `3.0.0-next.6` and vite `8.0.16` (details in #15461 (comment)), ssr-side hook time drops from ~296s cumulative to 23ms, the build succeeds, and a planted two-hop `$lib/server` violation still fails with the full chain. There is no new test because the behavior is meant to be unobservable and the exact chain assertions already exist in `test/apps/dev-only` (dev) and `test/build-errors/server-only.spec.js` (build), both green with this change. History for reviewers. #15439 added hook filters everywhere except this hook, which is blocked on vitejs/vite#21956. #15543 proposed this skip plus a node_modules importer skip and was closed pending kit 3. The ssr half was not fixed by kit 3. The node_modules half is not implemented here because it is unsafe, a library can legitimately import `$app/server` and its violation chain has to walk node_modules edges. --- ### Please don't delete this checklist! Before submitting the PR, please make sure you do the following: - [x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs - [x] This message body should clearly illustrate what problems it solves. - [x] Ideally, include a test that fails without this PR but passes with it. ### Tests - [x] Run the tests with `pnpm test` and lint the project with `pnpm lint` and `pnpm check` ### Changesets - [x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running `pnpm changeset` and following the prompts. Changesets that add features should be `minor` and those that fix bugs should be `patch`. Please prefix changeset messages with `feat:`, `fix:`, or `chore:`. ### Edits - [x] Please ensure that 'Allow edits from maintainers' is checked. PRs without this option may be closed.
fixes #14153. The one part I'm slightly nervous about is manipulating the errors that occur during the secondary build to avoid double-logging, though it's probably okay?
This is a radical simplification from what we had before. It results in consistent errors between dev and prod (no more 'build the app to figure out the import chain'), more readable errors (better formatting, more concise message, no useless stack trace), co-locates code better, is more efficient (instead of walking the entire module graph from the universal entry points, it walks up from a server-only module if/when one is found), and is a lot less code.
One very minor trade-off: it's no longer possible to differentiate between static and dynamic imports. I don't think this matters.
Not require ready to merge yet because FUCKING WINDOWSPlease don't delete this checklist! Before submitting the PR, please make sure you do the following:
Tests
pnpm testand lint the project withpnpm lintandpnpm checkChangesets
pnpm changesetand following the prompts. Changesets that add features should beminorand those that fix bugs should bepatch. Please prefix changeset messages withfeat:,fix:, orchore:.Edits