Bjorn Lu

Coming back to this, I think I misunderstood the initial problem before, and this fix sounds good to me. Thanks for setting up the repros to explain the problem. Given...

Actually looking deeper into this, I think there's still a way to make this non-breaking. > I've rebased the PR. I did have to add these vitepress devDependencies to the...

> * As you suggest, when bundling, do not externalize these dependencies. Can you help me better understand the externalization logic? What is the reason `body-scroll-lock` and `@vueuse/core` are externalized...

Yeah I think we can merge this in a minor now as it's non breaking.

While I'd like to see first-class support for this as well, unfortunately tsconfig paths and `resolve.alias` are not a one-to-one behaviour. - tsconfig paths are a lot more lenient and...

I'm not sure this issue is related to what you're getting. You can check https://vitejs.dev/guide/dep-pre-bundling.html#monorepos-and-linked-dependencies if you're working in a monorepo. Otherwise for your case in particular, perhaps you can...

I haven't started yet so feel free to take it too. The issue is likely that `transformRequest` (and some child function) is swallowing the error https://github.com/vitejs/vite/blob/d5fe92cd2a0be2b8636e876a81a63921a808afb2/packages/vite/src/node/ssr/ssrModuleLoader.ts#L88 Based on the behaviour...

I think this is supported now with the new [`vitePreprocess` API](https://kit.svelte.dev/docs/integrations#preprocessors-vitepreprocess).

I remember svelte2tsx's `emitDts()` function would silently fail if there are type errors in one of the components. I'm not sure if it's fixed yet though, but it may be...

Maybe related: https://github.com/vitejs/vite/issues/2483