Stop reloading the browser upon optimizeDeps changes?

[brillout]

I've always wondered: why does Vite reload the page when new dependencies to be pre-optimized are discovered? I'm probably missing something but I'm curious: why is that?

Naively, I would think that Vite could delay the HTTP response until it finishes optimizing the dependency.

[patak-dev]

The issue isn't about awaiting. The current code is non-blocking when optimizing as you expect.

Dependencies are optimized in batch because they share common chunks. When a new dependency is discovered, they all need to be re-optimized and if one of the common chunks between the old ones and the new ones changes... then the browser needs to reload because if not it could end up with duplicated state (think of internal react hooks state)

Some more info expanded from this thread: https://twitter.com/patak_dev/status/1530239669652299782

In 2.8, the scanning was done before the server start. In 2.9 we made it start after the server, and in parallel with the requests being processed. So the time it took was already not affecting that much overall, even if requests processing were blocked by it when transformed.
The scanner was needed because we wanted the most complete possible list of dependencies used in your project. In 2.8, each missing dep in this stage was triggering a full reload (there was some batching in place, but still, each batch was always a reload). So it was quite costly
This changed in 2.9, as we were able to avoid full reloads if the newly discovered batch of dependencies didn't modify the already optimized deps. So the scanner lost a bit of its edge there, but it was still an important piece in the puzzle
The problem with the esbuild scanner is that it doesn't apply your plugins, it bundles the user code with esbuild as quickly as possible only to get the imports. But if a import is added by a plugin, like with unplugin-auto-import then it is going to be missed
What vite@3.0.0-alpha.6 is doing is removing the scanner, and avoiding full reloads and missing deps altogether by delaying the optimization stage until every file in your source code is requested and processed. So deps added by plugins are properly discovered
The effect you'll see when you cold-start a project is that deps are now loaded after your code, while previously you will see in the network tab that deps finished first, and then modules importing it will follow. I hope the perf remains the same, but full reloads are avoided

[brillout]

The goal of the proposed approach is as well to decrease the number of modules sent to the browser: instead of sending n modules per npm package, only 1 module is sent per npm package.

But, yes, if an npm package, e.g. @vue/runtime-dom, is used by only one other npm package, e.g. vue, then the proposed approach would send one module for @vue/runtime-dom whereas with the current approach @vue/runtime-dom is included in the vue bundle.

So, with the proposed approach, it's one module per npm package, whereas with the current appraoch it's less. (Precisely: one less for each npm package that has only one depender.)

Cons:

• More files are sent to the browser. But my guesstimate is that number of user files > number of packages. To be verified but I believe most client-side (quality) libraries have a fairly small dependency graph. If my guesstimate holds true, then the increased number of files sent shouldn't be a problem.

Note that client-side dependency graphs have much less dependencies than server-side dependency graphs.

For example:

// package.json
{
  "dependencies": {
    "@mdx-js/mdx": "^2.1.1",
    "@mdx-js/react": "^2.1.1",
    "@mdx-js/rollup": "^2.1.1",
    "@types/express": "^4.17.13",
    "@types/node": "^17.0.31",
    "@types/node-fetch": "^2.5.12",
    "@types/react": "^18.0.8",
    "@types/react-dom": "^18.0.3",
    "@vitejs/plugin-react": "^1.3.2",
    "node-fetch": "^2.6.1",
    "react": "^18.1.0",
    "react-dom": "^18.1.0",
    "react-streaming": "^0.2.6",
    "typescript": "^4.6.4",
    "vite": "^2.9.7",
    "vite-plugin-ssr": "0.3.64"
  },
}

The server-side dependency grpah is 269 npm packages big (source: npmgraph.js.org), whereas the client-side dependency graph is only 9 npm packages big.

For this concrete package.json:

• Proposed appraoch: 9 modules sent. (One module per npm package.)
• Current approach: 6 modules sent. (Because 3 npm packages have only one depender.)

So the proposed approach sends 50% more modules.

But the idea here is that it's negligle because, AFAICT, what dominates the number of modules are user-land modules. In user land it's one module sent to the browser per user file.

The number of modules sent to the browser is one of the biggest limitations of Vite right now.

I wonder whether HTTP/2 can alleviate (completley fix?) the problem. TPC multiplexing is a primary goal of HTTP/2.

For readers other than patak: Vite + HTTP/2 discussion at #7611 (comment).

Another thing that could change the game could be to have web bundle support to send several modules in a single bundle at startup.

I wonder if we still need this in an HTTP/2 world.

If we do, I'm thinking a Service Worker may do the trick; service Workers are quite powerful.

[patak-dev]

I don't understand what are you proposing here. You can't send one module per dependency as you state here because the modules can have shared internal state. So you need to bundle everything together to find common chunks, or you need to not bundle at all sending the full 269 npm packages.

[brillout]

You can't send one module per dependency as you state here because the modules can have shared internal state.

The bottom line here is that a module should not be instantiated twice.

// node_modules/react/someModule.js

// The value of `someInternalState` should be shared across the entire app.
let someInternalState = {
  reactElementTree: { ... },
}

We cannot send node_modules/react/someModule.js twice (i.e. duplicate it) because it would mean that the value of someInternalState would get lost in the second instance.

In a nutshell: a module should not be duplicated.

With the proposed approach, the source code of one module sent for one npm package is immutable. This means once it's sent to the browser, the browser won't need to load it a second time. There is no duplication.

Also see what I said earlier:

dependencies need to be optimized altogether because they share code

When two dependencies share code it means that they have a common npm package dependency. That's the only way two dependencies "share code". Other than sharing a common npm pacakge, dependencies always have separate code.

That's why pre-bundling on an npm package basis is a more natural way of pre-bundling than what we do today.

This also means that npm packages can be pre-bundled independently of each other. (Note that, with my proposed approach, an npm package needs to be completely pre-bundled.

you need to not bundle at all sending the full 269 npm packages.

The 269 npm packages are for the server-side. We are speaking of the client-side here. For the client-side it's 9 npm packages.

For example, the Vite client-side is much smaller the Vite's server-side. The same goes for the dependencies: the Vite client-side uses few (zero?) npm packages, where as Vite's server-side (precisely speaking: Vite code that runs in Node.js) is much bigger and uses a lot more npm packages.

In a nutshell: the Vite client-side dependency graph is much smaller than the Vite server-side dependency graph. The same is also true for user apps. (Even for SPAs: e.g. the npm package typescript is never loaded in the browser.)

[patak-dev]

If you have N packages in the client, these may share internal dependencies and depend on each other. You need to bundle all of them together to know these ones. You can't bundle each package independently. If you bundle all of them together, you are doing the current approach. I think it is better to see a POC at this if at one point you or some other is interested in exploring this.

[brillout]

If you have N packages in the client, these may share internal dependencies and depend on each other. You need to bundle all of them together to know these ones. You can't bundle each package independently.

I disagree.

Let me recap. Pre-bundling is about three things:

1. CJS -> ESM conversion. (For npm packages that don't ship ESM but only ship CJS.)
2. Bundling npm packages. In order to reduce the number of modules sent to the browser.
3. Preserve internal states.

There is no problem with CJS -> ESM conversation, I think we agree on that.

About preserving internal state, see my previous reply.

About bundling, let me elaborate.

With the proposed approach, each npm package gets its own bundle. It's one bundle per npm package. (This means that an npm package bundle does not include any of its npm package dependencies.)

Each npm package can be bundled in isolation and there is no need to know the app's dependency graph. (That's why one could eventually implement a "Vite CDN" like Snowpack did back in the days.)

All in all, the proposed approach fulfills all three aforementioned points, which is what we want. Albeit with an increase of modules sent to the browser.

POC

That'd be great indeed.

I won't have time to implement a POC, but I'm happy to give input shall someone be up for the task.