Last 12 weeks · 30 commits
3 of 6 standards met
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 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 . The only public API available to it is (https://github.com/storybookjs/addon-svelte-csf/issues/355). only reads files, so options passed inline to the plugin in the Vite config are invisible to it — e.g. SvelteKit's inline options mode (), which even warns when a file exists. In such projects these tools silently miss and every other setting. The 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 already provides inside the plugin context. With that in place the log concern resolves itself: 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 by having each tool call Vite's 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 opt-out on — treats the symptom only; the tool would still miss inline options entirely. Demoting the log to debug level — regresses #1179, which deliberately chose info level for the accidentally-missing-config case. Callers replicating the config-file search ( is not exported) — duplicates internal logic and still cannot see inline options. Importance nice to have
This PR fixes a problem when using the svelte plugin with or (which is just a thin wrapper around ). The issue is that when there's multiple environment, and you use the hook is invoked before and since we assign to the object only in the other plugins that try to use fails. The solution is to retry to load the config inside (which despite the name is also invoked in dev) unless the api has already been configured. There's a problem, tho: other plugins also relied on . I tried different solutions like always using instead of (this failed when not using ), using a getter/setter for but none felt better than what I have here which is adding a callback registry to the object so that plugins can register there instead of using . I tried and it seems to work well but please let me know if you have better ideas.
Repository: sveltejs/vite-plugin-svelte. Description: Svelte plugin for https://vite.dev Stars: 1038, Forks: 140. Primary language: JavaScript. Languages: JavaScript (56%), TypeScript (28.6%), Svelte (12.8%), HTML (2.5%), SCSS (0%). License: MIT. Topics: svelte, vite, vite-plugin. Latest release: @sveltejs/vite-plugin-svelte@7.3.0 (1w ago). Open PRs: 6, open issues: 18. Last activity: 5d ago. Community health: 62%. Top contributors: dominikg, renovate[bot], github-actions[bot], bluwy, benmccann, teemingc, Rich-Harris, rixo, maxlath, baseballyama and others.