Provide a supported way for tools outside the Vite plugin context to resolve the effective Svelte options

[madonoharu]

Describe the problem

Tools that integrate with Svelte projects but run outside the Vite plugin lifecycle need the project's Svelte options. For example, the story indexer of @storybook/addon-svelte-csf runs in Storybook's core server, outside (and possibly before) the preview Vite instance, so it cannot read the resolved options the plugin exposes as api.options. The only public API available to it is loadSvelteConfig() (storybookjs/addon-svelte-csf#355).

loadSvelteConfig() only reads svelte.config.* files, so options passed inline to the plugin in the Vite config are invisible to it — e.g. SvelteKit's inline options mode (sveltekit(config)), which even warns when a svelte.config.js file exists. In such projects these tools silently miss preprocess and every other setting.

The no Svelte config found at ... - using default configuration. info log (#1179) makes this worse: in an inline-options project the message is factually wrong — the project does have Svelte configuration and the effective options are not the defaults — and since it fires inside the public utility, the calling tool can neither suppress nor correct it. (In the Storybook case it was printed once per stories file, 98 lines in a single build; the addon is fixing the repetition by caching, but the remaining line is still misleading.)

Describe the proposed solution

Provide a supported way for out-of-plugin-context consumers to obtain the effective (inline + config file) options — for example an exported helper that takes a resolved Vite config, locates the svelte plugin, and returns its resolved options: essentially exposing what api.options already provides inside the plugin context.

With that in place the log concern resolves itself: loadSvelteConfig() can keep its current behavior for the plugin's own resolution path, and tools no longer trigger a misleading "using default configuration" message in projects that are configured inline.

Happy to send a PR if you can point me at the preferred shape.

Alternatives considered

• Reaching api.options by having each tool call Vite's resolveConfig() itself — heavyweight (it executes the user's whole Vite config and all plugin config hooks) just to read a few options, and indexer-style hosts offer no natural place to do it once per project.
• The original framing of this issue: a { logMissing: false } opt-out on loadSvelteConfig() — treats the symptom only; the tool would still miss inline options entirely.
• Demoting the log to debug level — regresses fix: log missing config at info level #1179, which deliberately chose info level for the accidentally-missing-config case.
• Callers replicating the config-file search (knownSvelteConfigNames is not exported) — duplicates internal logic and still cannot see inline options.

Importance

nice to have

[teemingc]

Both should probably move to https://github.com/sveltejs/language-tools/blob/master/packages/load-config/package.json which is the new official utility for loading a Svelte configuration