unprocessed `.svelte` files in transitive dependencies within a monorepo

[AdrianGonz97]

Describe the bug

It seems that vite-plugin-svelte doesn't process the .svelte files from transitive dependencies when those files come from the package's devDependencies, which arguably feels a bit unexpected in the context of a monorepo with private local packages.

In this example, we're importing a svelte component from @lucide/svelte (which is installed as dev dep) in the ui package for a Button component that is then used in the site app.

The idea behind this monorepo setup is to have a local ui package that isn't necessarily published to npm, so the dependency-type for each dependency of that package 'shouldn't really matter' as the dependency will always be resolvable.

One solution (if not, the solution) would be to move the @lucide/svelte dependency in ui to dependencies. However, I think it's worth questioning whether this should be necessary at all if the dependency is locally resolvable.

Reproduction URL

https://github.com/AdrianGonz97/unresolvable-dev-deps-svelte-monorepo

Reproduction

1. clone https://github.com/AdrianGonz97/unresolvable-dev-deps-svelte-monorepo
2. run pnpm i && pnpm dev
3. navigate to http://localhost:5173

Logs

11:56:17 AM [vite] (ssr) Error when evaluating SSR module /src/routes/+page.svelte: Unknown file extension ".svelte" for /home/koala/Reproductions/unresolvable-dev-deps-svelte-monorepo/node_modules/.pnpm/@lucide+svelte@0.511.0_svelte@5.33.1/node_modules/@lucide/svelte/dist/icons/bubbles.svelte
      at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:219:9)
      at defaultGetFormat (node:internal/modules/esm/get_format:245:36)
      at defaultLoad (node:internal/modules/esm/load:120:22)
      at async ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:580:32)
TypeError [ERR_UNKNOWN_FILE_EXTENSION]: Unknown file extension ".svelte" for /home/koala/Reproductions/unresolvable-dev-deps-svelte-monorepo/node_modules/.pnpm/@lucide+svelte@0.511.0_svelte@5.33.1/node_modules/@lucide/svelte/dist/icons/bubbles.svelte
    at Object.getFileProtocolModuleFormat [as file:] (node:internal/modules/esm/get_format:219:9)
    at defaultGetFormat (node:internal/modules/esm/get_format:245:36)
    at defaultLoad (node:internal/modules/esm/load:120:22)
    at async ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:580:32) {
  code: 'ERR_UNKNOWN_FILE_EXTENSION'
}

System Info

System:
    OS: Linux 5.15 Ubuntu 22.04.5 LTS 22.04.5 LTS (Jammy Jellyfish)
    CPU: (24) x64 AMD Ryzen 9 5900X 12-Core Processor
    Memory: 10.94 GB / 31.30 GB
    Container: Yes
    Shell: 5.8.1 - /usr/bin/zsh
  Binaries:
    Node: 20.19.2 - ~/.volta/tools/image/node/20.19.2/bin/node
    Yarn: 1.22.22 - ~/.volta/tools/image/yarn/1.22.22/bin/yarn
    npm: 10.8.2 - ~/.volta/tools/image/node/20.19.2/bin/npm
    pnpm: 10.9.0 - ~/.volta/bin/pnpm
    bun: 1.1.38 - ~/.bun/bin/bun
  Browsers:
    Chrome: 127.0.6533.119

[dominikg]

https://github.com/AdrianGonz97/unresolvable-dev-deps-svelte-monorepo/blob/main/ui/package.json

is missing the svelte exports condition and lucide must be a dependency in this case as it is required in the consumer. you could make it a peerDependency maybe but i don't think that's better than a dep.

if you really insist using a devDependency here you could configure hoisting but i would not recommend that either.
What is your goal?

[AdrianGonz97]

What is your goal?

we're currently in the process of adding monorepo support to the shadcn-svelte cli, so I was getting a feel for how the project should be structured when i ran into this issue.

at the moment, shadcn-svelte installs the dependencies for components as devDependencies. originally, they were installed as dependencies until we started getting constant requests (e.g. a, b, c and however many more we got on discord) to switch them to devDependencies.

personally, i think they should've stayed as dependencies and would be open to changing it back, which we may very well do if this issue is the reason for it

[dominikg]

in my opinion monorepo provided dependencies need to follow the same restrictions as regular dependencies.

you don't get access to devDependencies of packages you install from the registry, so why do you expect otherwise? if you want to manage versions of shared dependencies, use monorepo tooling like pnpm catalogs.

the install --production case is not going to add .svelte files to that because in the case where app A has a devDependency B with B having a dependency on C, C is not included.

note that pnpm also has a command called deploy which can help to get the minimal node_modules for deployment

[dominikg]

this isn't an issue nor caused by vite-plugin-svelte, it's about monorepo use in general. I'll close this here, please start a thread on svelte discord if you want to discuss

[benmccann]

The dependencies vs devDependencies question depends what you're building and type of package. If you're building a library then you'd want packages providing .svelte files you reference in dependencies. If you're building an app, you'd want them in devDependencies. Feel free to start a thread with us on Discord. I've spent way too long on packaging and have a pretty good feel for it now

[huntabyte]

I want to respectfully push back on closing this as "not planned" because I think there's a real inconsistency here that's causing practical problems for many users (we receive multiple per week in our Discord / GH issues related to Bits UI and monorepos).

The core issue isn't really about monorepo dep management theory - it's that .svelte files are treated differently than other modules. If I have a local package that imports a .js file from a transitive devDep, it works fine. But the exact same import with a .svelte file fails. This feels like a bug, not expected behavior.

I get the argument about following "the same restrictions as regular deps" but monorepos with private packages aren't really regular dependencies. They're part of the same build process and will never be published. Forcing people to restructure their dependency trees just to work around this plugin limitation seems backwards.

Sure, catalogs exist, but requiring users to adopt specific monorepo tooling and restructure their entire dependency management just to make .svelte files work feels like we're forcing architectural decisions to workaround a plugin limitation rather than fixing the underlying inconsistency.

I'm not asking for a complete overhaul, but maybe the plugin could be smarter about this? Like falling back to normal Node module resolution when a strict dep check fails. If Node can resolve the .svelte file, why shouldn't the plugin be able to use it?

[dominikg]

vite-plugin-svelte does not resolve .svelte files, it just configures vite to tell it about the "svelte" exports condition and main field.

[dominikg]

please provide a minimal reproduction where a .js file is resolved from a transitive devDependency and a .svelte file is not, despite it being exported via the svelte condition.