Discussion: Future Plans

[yyx990803]

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)

[csr632]

Could we make Vite helpful to library development (like storybook.js) ? https://github.com/vitejs/vite/issues/330 https://github.com/vitejs/vite/issues/725

[cisen]

• [ ] https://github.com/vitejs/vite/issues/257, Multi-page

[aleclarson]

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).

Skeptical whether it's worth the plugin churn. Is there an example where the current design makes plugin development unbearable, or at least makes code reuse impossible?

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)

Which parts of the resolver API could be simplified? What are the benefits of using resolveId-style API?

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

Vite currently lazy-loads all modules, and this idea goes against that. Is the dent on startup time worth it? Maybe it could be an option (eg: optimizeDeps: { deepScan: true }).

[intrnl]

Would it suffice if we take parts of WMR that already works great (rollup plugin driver, css chunking on build, etc.) and make it usable for Vue and any other uses?

Some Vite plugins are already wrappers around their respective Rollup plugins (e.g. svite), and I think it would be a good idea if Vite would follow what Rollup plugin API has to offer, instead of the other way around (adapting a Rollup plugin as a Vite plugin), but still allowing any additional Vite-specific hooks if it comes down to it (e.g. serverMiddleware hook).

[arpowers]

The proposed improvements sound great.

I don't think the breaking changes proposed would take more than a few hours to fix in any particular project. Additionally, there aren't many highly usable plugins in the wild so you shouldn't worry about breakage too much.

My guess is that the things that have been frustrating will be addressed by your changes (SSR features and aliasing quirks).

[underfin]

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).

That is very important for prevent ecosystems are fragmented between dev and build. I remember that the user often encounter the inconsistent behavior between dev and build when project is growing, and also the project test is complex for some edge case.

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)

My opinion as same as @aleclarson. The cost is expensive for scan imports in the codebase, we should retain the option for users manually optimize their porject.

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)

For this, we should consider the css @import alasing (https://github.com/vitejs/vite/issues/650) and the asset alasing inside template and css(https://github.com/vitejs/vite/issues/913).

[underfin]

@csr632 I think it can be improved if has a new plugin system. For now the vite internal maintainer a html plugin of build and also the html used inside dev, it is can be separate into single plugin.

[remorses]

1229, resolve node_modules as normal paths and support importing from outside root (../..)

[jods4]

@yyx990803 How do you feel about Snowpack now, as opposed to when Vite started?

In the Why and How? doc you highlighted differences when you started Vite, but it seems to me that over time, those differences vanished... or could vanish.

Snowpack also supports HMR nowadays, and Vue works out of the box. In v3, building for production is a plugin, so you could use rollup if you prefer that to webpack or esbuild (their new default).

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

Snowpack is also built on a plugin model, so it really makes me wonder if there shouldn't be some synergy here. Why duplicate efforts?

Seeing how both projects evolved, don't you think it may make more sense to merge Vite into Snowpack 3 contributions? You could improve their Vue support with what you learnt when building Vite and they have all the other "generic web server" stuff figured out.

[arpowers]

@jods4 interesting points. The SSR approach they've outlined really sounds awesome to me. I've mentioned this before as Vite requires a build currently and can't support SSR in dev.

[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.

[yyx990803]

@arpowers rest assured you can do something similar in Vite 2.0.

[ghost]

@yyx990803 Is there a release schedule for the v2 version? Am looking forward to

[jods4]

@yyx990803 very interesting insight, thanks!

[ais-one]

I think the plan sounds about right.

Putting out v1 for those who have already put things out in production, with the caveat the limitations of further development/support.

The focus should be on v2 based on lessons learnt from v1.

Even VueJS had changes from v1 to v2, with v2 gaining traction very well over time.

[yyx990803]

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

[arpowers]

Looks much improved Evan. In particular, the organization is easier to follow. WIll be looking forward to the breakdown of changes; I can already tell this will solve many of the early issues my team has had to work around.

[frandiox]

Awesome! Would it be too hard to make v2 compatible with ESM projects (those that include "type": "module" in their package.json) without patches?

[peey]

I also wish to request taking care of some security concerns https://github.com/vitejs/vite/issues/537

[arpowers]

Don't forget about PostCSS 8 support (for tailwind) ... https://tailwindcss.com/docs/guides/vue-3-vite

[underfin]

As https://github.com/vitejs/vite/issues/1253 mention, Here hasn't plateform of dicussion at now and hasn't offical docment.It is very important for vite communtiy, it should be listed on the vite2.x.

[MartinMalinda]

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)

I'm not sure if that would be addressed, but the only pain point with vite right now to me is that the initial page load can be slow (5+ seconds in my case) if there's a lot of modules loaded right away. I could ease the issue by doing more imports async but I don't want to code split more just for the sake of better DX. I'll try to experiment with something like: async import in dev / sync import in production for page components in the router. But it would be awesome if this issue improved in general... in some way:))

[yyx990803]

Closing this now that 2.0 is in beta. Some of the todos like SSR is tracked in their own dedicated issues. New docs available at http://vitejs.dev/

Re @MartinMalinda - I think we can open another issue specifically dedicated to improving first load speed. I think Vite 2's strong caching of dependencies should already improve that to some extent - for user source code, the possible solution is fs-based persistent cache. We can dump the cached module transform results to disk on server close and reuse it on the next server start.