Position on supporting non-Vue, non-Svelte SFC formats?

[ryansolid]

We've been looking at Vite with Marko and came across a number of places that seem to be hardcoded(1, 2, 3) to proprietary SFC extensions. Would the project be open to other libraries making PR to add SFC extension support for things like Marko or Riot etc.. I'm thinking it might not be as simple as adding the extension to the list.

Are there any plans to expose access to ESBuild's prebuild setup to support scanning of different dependency types?

Any recommendations?

[patak-dev]

I think that for established extensions, we should just add them to the list. But all that three places should be configurable because it would be impossible to list all possible extensions. PRs welcome.

About supporting different dependency types in the scanning stage, @yyx990803 commented in the request to support Flow that we would need to add plugins to that stage too: #2238 (comment). So looks like this is also a welcomed enhancement.

[ryansolid]

When you say PRs welcome, I'm gathering you don't mean just adding .marko to the lists. Because if that were the case I'm sure I could get that up in a heartbeat. Maybe this should be made into an issue where we can track/discuss a specific solution to the problem.

[dominikg]

There's also

vite/packages/vite/src/node/utils.ts

Line 106 in fa85749

const knownJsSrcRE = /\.((j|t)sx?|mjs|vue)($|\?)/

For dep scanning it could get hard though as it's impossible to reliably scan dependencies from unknown formats without actually transforming them with their plugins first

[DylanPiercey]

Would it be possible register an esbuild hook which would match anything but the "known file extensions" and defer to the vite plugins for both resolve and load?

[ryansolid]

Yeah I'm not sure if it is completely related but we have hit some issues with Solid where the entry point of a Node Module is JS, but imports nested JSX and doesn't know to use our custom transform (which looks for JSX extensions) instead of the stock ESBuild one when it isn't the extension of the entry. I believe it works fine in prod builds but in dev mode we end up with some React looking code in there. We can obviously exclude it manually but resolution of extensions where ever they are hit would be nice. This is probably slightly different issue but it has to do with decision over pre-bundling optimization I believe and how you end up all in on ESBuild once you down that path. To be fair I use a custom field/import condition so I could probably inspect package.json and use that instead of extension to make these decisions. But wanted to share in case it had any impact on solution.