Breakup vite-env.d.ts types

[devinrhode2]

I'm weary about making changes for my app which tie it to a specific bundler/compiler. As good as vite appears to be today, there will inevitably be another bundler/compiler which I may want to try out. (Perhaps, discover which one produces the smallest bundle size)

While I love that vite has TS types, I'd like:

1. Breakup these types into specific categories

• Import SVG as react components
• Import SVG as file url strings
• import.meta.env vars
• HMR api, i.e. import.meta.hot

The goal here is similar to babel moving away from large "presets".

Instead of having one large kitchen sink that all projects use, break them up into smaller bits and pieces.

Some projects may even want type defs that prevent usage of bundler-specific features.
Avoiding global type defs would also be great, but I'm not sure how possible that is.

[devinrhode2]

Lastly, I wonder if there's a place for some standards to evolve here.

The FE build ecosystem has been expanding, it'll probably continue to expand for quite some time, until some project becomes good enough to gain a certain dominance in the market.

Improving portability of code will mean we get a more competitive landscape, we can all make more informed decisions, hopefully by simply trying out different bundlers.

Non-standard/bundler-specific features are like stage-0 syntax.

I like stage-3 syntax.

I'll even settle for stage-2.

Maybe we can categorize these various technologies as stage 0/1/2/3, and let developers opt-into what they need, when they need it.

• Import SVG as react components
• Import SVG as file url strings
• import.meta.env vars
• HMR api, i.e. import.meta.hot

Similarly, if some of these api's are completely unique to vite, they could be prefixed with "vite-", such as "vite-pbj"