Bjorn Lu

I don't know if this would fix it, but Astro has a `file://` plugin [here](https://github.com/withastro/astro/blob/cf65476b27053333cf5a36f6f9f46b794c98dfa2/packages/astro/src/vite-plugin-fileurl/index.ts#L3-L13), and I'm guessing it's a matter of marking it `enforce: 'pre'`. Let me see if...

For me (and also mentioned in the meeting), I think it would be nice if Vite can support it in the future, and this is also more of a stop...

I think either way works for me, but since this will be merged in the next major, it shouldn't have a big impact in practice.

In our meeting notes, we decided to not externalize `file://`. However in https://github.com/vitejs/vite/pull/18422 we decided to support `file://` in client and ssr. So I think we can merge the PR...

The env var docs in the config page applies to the vite config. The env var docs in "env and mode" applies to the vite app. I think they're both...

Closing as there hasn't been a response from OP

I'm personally not very comfortable with using a global function to handle the dynamic imports, and the stack trace issue also feels like a can of worms. We're switching tradeoffs...

They don't have a way to disable the cache recursively and track the files loaded to be watched for changes, so not really a 1:1 feature parity with the current...

It would be kinda nice to have this builtin I think, but it's tricky to always show by default because qrcode rendering don't always render well on all terminals. It's...

We've discussed this in the last team meeting and decided to support `.js` -> `.ts` resolving for JS files too based on the related `tsconfig.json`/`jsconfig.json` that has the special resolution...