Scope of experiments

[antfu]

Hi @speray, if you didn't get it wrong, you were talking with me about the bottleneck of Vite's network request in Strasbourg (sorry if I made a mistake).

We, the Vite team, want to explore this direction a bit, as we consider it quite a common issue in Vite. This repo is a very basic PoC I made in 15mins, but it seems to work in general. It would be great to have some feedback on different usage/needs when working with large-scale apps.

(thanks to @edimitchel for the info!)

[seho-dev]

@antfu

The prebundle vite plugin seems to do the same thing as farm, and I think you can refer to farm's Partial Bundling strategy.

https://github.com/farm-fe/rfcs/blob/main/rfcs/001-core-architecture/rfc.md#8-partial-bundling-and-resource-generation

[speray]

Thanks @antfu !
Sorry for the late answer, I was out for the last 2 weeks. I will take a look.
Thanks!

[speray]

I had a quick look. First thanks again @antfu for putting this together and spending your time based on a simple feedback at a meetup, it's really appreciated.

The situation I'm in is the following:

• We have a very large codebase with thousands and thousands of files. They form a complicated graph and are not really grouped together. That means it's pretty common to have a file in dir1/featureA/sub1/foo/bar.ts to import dir2/featureB/sub2/baz/bbb.ts. It's organized as a monorepo and dir1 and dir2 here have some aliases which provides clarity, but the imports are still deep (dir1 isn't really organized as a package reexporting some kind of "public" things, it's just some grouping).

• Since the codebase if huge, some dirs are very rarely updated. Let's say dir3 and dir4. Some are changed often but by other teams, let's say dir5 and dir6. I don't have the knowledge of the entire repo structure, but I can identify the place I'm working on and where I'm most likely going to change files. Let's say in dir1/featureA.

• I think what I'd like would be to be able to express in a config file something like "Bundle when possible, everything except what is under dir1/featureA", so that modules in dir1/featureA get served individually to get nice HMR possibilities, and group the rest to avoid generating too many requests.

I understand this implies some complexity since dir1/featureA may import dir4/foo.js which was also imported by dir3/bar.js and which should really prevent duplication as it can create some strange runtime weirdness with object comparaisons for example.

If an initial pass is needed to determine which modules are indirectly referenced by the "working folder" like dir1/featureA to build some kind of mapping, that's totally fine as people tend to work on a given part of the codebase for a while and this doesn't change often. Also, even if it does happen to update a file outside of my working folder, it's fine to do a full reload as this is super rare.
In the end this looks a lot like the current strategy currently used by vite to treat node_modules which creates intermediate shared chunks, but little more hybrid.

I don't have deep knowledge on the internals of vite, so I may have been inaccurate, sorry if that's the case.

In the playground example, if I understood correctly, as soon as submodule2 references submodule1/something, it duplicates the module content which could be an issue (not really because of the size, but more about the correctness).

Thanks a lot for the followup!