fix: don't log an error for vite configs without a Svelte plugin

[Socialpranker]

Partially addresses #3080.

What this fixes

Since 4.6.0 the config loader crawls for vite.config.* files. In a monorepo that means it also visits packages which don't use Svelte at all, and for each of those it logs an error:

Error while loading config at  .../packages/package-a/vite.config.ts
Error: No Svelte configuration found in vite config. Is @sveltejs/vite-plugin-svelte configured?

package-a not using Svelte isn't a problem, so reporting it as an error is misleading — the reporter in #3080 hit exactly this.

loadConfig already distinguishes the two cases, it just wasn't being used to: a config that genuinely fails to load comes back as { error, ... }, while a config that loads fine but has no Svelte plugin falls through and comes back as undefined. Only the first is an error. This checks result?.error and keeps Logger.error for that case, logging the other at the normal level.

Everything else is deliberately untouched. The fallback preprocessor and loadConfigError are still set exactly as before, so the retry logic in loadConfigs (!config || config.loadConfigError), addFallbackConfig, and the diagnostics path in getDiagnostics.ts all behave identically. This is only about the log level.

What this does not fix

#3080 raises a second, larger question: how svelte-check should work in a monorepo with several Svelte packages, each with its own vite.config.ts, when --config takes a single path. That's a design question about --config/ExplicitConfigScope rather than a bug, so I left it alone — happy to follow up if you decide on a direction.

Verification

Two tests added, both driven from the actual behaviour rather than written to match the patch:

• no svelte plugin → no error logged. Fails on main (Logger.error is called with the "No Svelte configuration found in vite config" message), passes with the fix.
• config genuinely fails to load → error still logged. Passes both before and after, i.e. it pins the behaviour the fix must not break.

The second test builds ConfigLoader directly rather than through the createConfigLoader helper, because that helper always wraps its result in { config } and so can't express a failed load. I found that out by tracing what the mock actually returned — my first attempt at the test passed for the wrong reason.

Checks run locally on Node 22:

• configLoader.test.ts: 15 passing.
• Full svelte-language-server suite: 819 passing, 21 pending, 3 failing — all three in SvelteCheckTSGoDiagnosticsProvider. Those also fail on a clean main (5 failing there, the set moves between runs), so they're pre-existing and unrelated to this change.
• prettier --check clean on the touched files, tsc --noEmit exits 0.

Changeset included.

Written with Claude Code (Claude Opus 5); I reviewed and tested everything before submitting.

[changeset-bot]

🦋 Changeset detected

Latest commit: d49eefd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
svelte-language-server	Patch
svelte-check	Patch

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

[dummdidumm]

thank you!