[Vite 3] Pre-bundling not discovering all dependencies

[brillout]

Describe the bug

Vite 3's pre-bundling phase doesn't seem to discover all dependencies leading to a full page reload.

Reproduction

https://github.com/brillout/vite3-prebundler-bug

System Info

System:
    OS: Linux 5.10 Debian GNU/Linux 10 (buster) 10 (buster)
    CPU: (2) x64 Intel(R) Celeron(R) N4020 CPU @ 1.10GHz
    Memory: 333.75 MB / 2.71 GB
    Container: Yes
    Shell: 5.0.3 - /bin/bash
  Binaries:
    Node: 18.0.0 - ~/.config/nvm/versions/node/v18.0.0/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.6.0 - ~/.config/nvm/versions/node/v18.0.0/bin/npm
  Browsers:
    Firefox: 97.0.1
  npmPackages:
    @vitejs/plugin-react: ^1.3.2 => 1.3.2 
    vite: 3.0.0-beta.10 => 3.0.0-beta.10

Used Package Manager

pnpm

Logs

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[patak-dev]

@brillout I can't reproduce in MacOS, weird because linux should work in the same way regarding paths. You also need to use @vitejs/plugin-react 2.0.0-beta.1, could you try that?

[brillout]

Indeed 2.0.0-beta.1 seems to fix it.

I still get 6:00:21 PM [vite] ✨ new dependencies optimized: react, react-dom/client, but without 11:22:24 AM [vite] ✨ optimized dependencies changed. reloading and the page indeed doesn't reload.

A little bit confusing is that the log ✨ new dependencies optimized: react, react-dom/client shows up randomly. Sometimes it is logged, sometimes not (even if I consistently run rm -rf node_modules/.vite before running the dev server).

I'll try to reproduce the ✨ optimized dependencies changed. reloading logs we were observing on vite-plugin-ssr's CI.

In the meantime I guess we can close this.

[brillout]

I tried to reproduce it, without luck. Let's hope it was a glitch, somehow.

[patak-dev]

With DEBUG=vite:deps I get

Server running at http://localhost:3000
  vite:deps scanning for dependencies... +0ms
  vite:deps no dependencies found by scanner +5ms
  vite:deps deps bundled in 12.66ms +14ms
  vite:deps ✨ static imports crawl ended +8s
  vite:deps ✨ new dependencies were found while crawling that weren't detected by the scanner +1ms
  vite:deps ✨ re-running optimizer +0ms
  vite:deps new dependencies found: react/jsx-runtime, react/jsx-dev-runtime, react, react-dom/client +1ms
  vite:deps deps bundled in 51.86ms +53ms
  vite:deps ✨ dependencies optimized +0ms

Looks like the scanner isn't finding anything because there are no entries or index.html to check. I think you should add the pages to the entries for vite-plugin-ssr, depending only on deps found with static crawling is going to cause some reloads (every time the deps are discovered in a dynamic route and has some chunks in common with the previous ones).
Also, all these deps react/jsx-runtime, react/jsx-dev-runtime, react, react-dom/client should be in optimizeDeps.include already for a react project. We should add them to plugin-react if they aren't yet there

[brillout]

So setting optimizeDeps.entries to all the user's page files is the recommended approach with the latest Vite 3 version?

In other words:

config: () => ({
  ssr: { external: ['vite-plugin-ssr'] },
  optimizeDeps: {
    entries: [`**/*.page.${javascriptFileExtensions}`, `**/*.page.client.${javascriptFileExtensions}`],
  },
}),

I just tried that and the scanner finds all dependencies 👌.

I'm wondering whether adding all the user's page files could considerably slow down dev start. Scan completed in 272.06ms for a fairly small app, so I'm thinking it may take too much time for a larger app. I'll ask my users that I know to have a large codebase.

[patak-dev]

This is a tradeoff with the scanner, and one of the reasons we wanted to remove it. It would probably depend on the user app. For small apps, it is a good default, for larger apps, the best would be to only scan the most common routes, and accept that there will be a reload when visiting some other routes for the first time.

We found that esbuild is quite slow when called with a lot of entries, so a possible optimization could be to aggregate all the entries and import them from a dynamically generated single file (for example for your .jsx routes, I think it will be possible) and feed that as the only entry to the scanner.

[brillout]

vite-plugin-ssr now has both techniques implemented (heuristic determining what pages files should be scanned + aggregate file). Thanks for the tip!