Bjorn Lu

Looks like a bug with the compiler. It generates code like this: ```js return $$render``; ``` We probably need to update https://github.com/withastro/compiler/blob/face55431403f20d81c4b5cd3cc4173320632ad9/internal/transform/scope-html.go#L148-L153 to generate `(undefined ?? '')` instead.

👍 Alright thanks! The state of the PR is fine by me in this case.

Currently, TS source code doesn't resolve aliases from `compilerOptions.paths` too. If we do in the config, it'd need to align with the source code. But the discussions about that are...

If tsconfig alias would work in a config file, it should also work in your source code files for consistency.

> But technically it does work if `resolve.alias` is added right? Yes, but `resolve.alias` has different resolve behaviour compared to tsconfig paths. Tsconfig paths is more lax and could map...

Closing this as it's something we don't plan on supporting for now.

Thanks for the investigation and proposing a solution. This makes sense to me and it would be nice to remove the proxy altogether. I'll run the PR on ecosystem-ci to...

We've discussed this before ([Discord thread](https://discord.com/channels/804011606160703521/823110545266835456/1094327606771462304)) and are open to trying it in Vite 5. The main blocker for me is that `@parcel/watcher` isn't publishing precompiled binaries like `lightningcss` and...

How so? Vite is already using esbuild. And has ecosystem support for SWC and lightningcss.

I made two branches to test it out: - `@parcel/watcher`: https://github.com/vitejs/vite/tree/bluwy-parcel-watcher - `fs.watch`: https://github.com/vitejs/vite/tree/bluwy-fs-watch Made `fs.watch` mainly because we need a wrapper for `@parcel/watcher` to work, and that wrapper can...