What is the recommended way to handle Svelte components in a monorepo environment?

[aym-i]

Hello,
As mentioned in the title, what is the recommended way to handle Svelte components in a monorepo environment?
I'm migrated components to a package separate from the web app, and I'm suffering from tsconfig.json issues and $app and other aliases IDE errors and fears of a shared stare (FYI I have an SPA)
I want to know what's the best way to solve these issues and build something I described?

[webJose]

If you have a SPA, then you shouldn't fear shared state, as there won't be a NodeJS server running your code.

As for TS issues: Use a Sveltekit project to create a Svelte component library.

[aym-i]

I see, would that create conflicts between the two Svelte projects?

[webJose]

No, because the Sveltekit project that is holding the components is never "run", is "packed", producing a /dist folder from where your other project reads.

[Nic-Polumeyv]

The $app alias errors are the expected part: $app/* modules only exist inside a SvelteKit project, so components moved into their own package lose access to them. The documented way out is to make the shared package framework-agnostic: import { BROWSER, DEV } from 'esm-env' instead of $app/environment, and take things like the current URL or navigation callbacks as props instead of reading $app/state (see the best practices section of https://svelte.dev/docs/kit/packaging). That also clears the IDE errors, since there's nothing left for the editor to fail to resolve. Keeping $app imports is only viable if every consumer will itself be a SvelteKit app, in which case declare @sveltejs/kit as a peer dependency and the consuming app's build resolves them; since yours is an SPA, the esm-env route is the one that fits.

The tsconfig side sorts itself out with the library template (npx sv create, pick the library option): svelte-kit sync generates the .svelte-kit/tsconfig.json your package's tsconfig extends, which is what keeps $lib and the Svelte types lined up without hand-rolled paths.