Would this mean that we let esbuild resolve instead? Wouldn't that possibly diverge from Vite's resolver that we want to use instead?

Maybe we can fix this issue by enabling experimentalDecorators by default only for scanning Looks like I explicitly removed experimentalDecorators support in scanning. Hmm I'm confused though why esbuild doesn't respect the tsconfig if we manually resolve.

Hmm true.
It seems esbuild doesn't support reading tsconfig.json if the plugin resolved the path (evanw/esbuild#2265).

related code: the part resolving tsconfig, resolver (res.Resolve calls finalizeResolve which resolves tsconfig)

As much as I'd like to avoid it, maybe reverting and enabling back experimentalDecorators for scanning would be the easier way for now 🤔 I think it shouldn't hurt too much since we only need to scan things.

Reading microsoft/TypeScript#50820, it seems there's some incompatibilities between the syntax of them unfortunately. 😢
Example 1 .(private fields), Example 2 (class expressions) (the error disappears if experimentalDecorators is set to false)

Dang, perhaps what we can do for now is manually read the project's tsconfig.json and then infer experimentalDecorators from there? Seems like there will always be a tradeoff, but worst case they could manually disable/enable it with esbuildOptions.tsconfigRaw perhaps.