Discussion: Future Plans

First of all, I think I rushed it when I put Vite under 1.0-rc state. There are definitely still some rough edges that I want to improve that may result in non-trivial breaking changes:

• I want to refactor into a plugin structure that allows better reuse of logic between the dev server and the production build (similar to WMR’s universal Rollup plugin interface). This will also replace the current transform API, and better separate the concept between “server middleware” and a “file transform”. Additionally, this allows the dev server to expose an API to apply all transforms to a given file without going through the server middleware chain, which has non-trivial overhead (such an API is needed when I was investigating SSR support in Vite).

• We may also want to rethink the file aliasing/resolver handling to make it simpler (e.g. using resolveId from the unified rollup plugin interface instead)

• Move Vue specific logic into its own dedicated plugin (this also gets rid of all Vue-specific config options)

But looks like there is already an ecosystem growing, so there’s already some compatibility concerns to be taken into account. Since ranges like ^1.0.0-rc will allow installing 1.0.0, I think we should call it 1.0 and release it in its current state and leave the breakage for 2.0.

Some non-breaking improvements:

• Smarter dep optimization for deep imports. We should use es-module-lexer to scan imports in the codebase so we know exactly what deps to include in the dep optimization step (this avoids the need to manually exclude/include when using deep imports)

• Error overlay (currently failed compiles often result in blank screens with errors only in the console)

• Better logging (avoid spamming console with the same message over and over)

[yyx990803]

https://github.com/vitejs/vite/tree/2.0 (WIP)

[yyx990803]

@jods4 re Snowpack:

Vue works out of the box

It works, but there’s no real Vue HMR. Snowpack 's “Vue HMR” actually remounts the entire Vue app on every update. Not to mention fine-grained style/template HMR without blowing away component state. We could probably figure out how to get the same level of HMR support via Snowpack’s API, but it’s duplicated effort and is most likely going to be less efficient than what is already available in Vite.

building for production is a plugin, so you could use rollup if you prefer that to webpack or esbuild (their new default).

Since Vite’s goal is to provide a full toolchain that includes an opinionated build setup and that Snowpack does not actually do that, we still need to absorb the complexity of the production bundling. Splitting dev-time special logic in Snowpack and build-specific logic in a custom plugin (which is constrained by how Snowpack outputs its build assets) actually would result in more complexity than having a single system that unifies both.

Snowpack is also built on a plugin model

Snowpack plugins are not compatible with Rollup plugins. One of the goals of Vite v2 is to actually support a superset of Rollup plugins that works for both dev and build (e.g. I already got rollup-plugin-vue, @rollup/plugin-node-resolve and @rollup/plugin-alias working without modification in the local prototype).

v3 has cool new features like npm install-less development.

I’m actually not sure if this is even a good feature to have. Looking from their docs I have a number of questions:

• How do you specify version ranges? If you put it inline, you’ll have to make sure to use the same version everywhere you import that dep. If not, you still need to use an explicit dependency config file. This is the same problem with Deno.

• This model requires you to all-in on Skypack, because Skypack packages are pre-compiled with all peer dep package cross-imports pointing to their Skypack URLs as well. That is to say, you can’t mix this model with traditional local npm installs. It’s Skypack or nothing. And if one of your deps doesn’t work on Skypack (which happens more than you think), your have to bail out. This also touches on something that bothers me a bit with Snowpack: that it’s owned by a startup that is using it as a strategy to promote its paid product. (Correction: Skypack is not a paid product, but it’s hard to imagine that a startup is building a CDN without future monetization in mind). I just don’t feel comfortable betting the future of Vue tooling on Snowpack.