Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

[Vite 3] Pre-bundling not discovering all dependencies

See original GitHub issue

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.

Issue Analytics

State:
Created a year ago
Comments:7 (7 by maintainers)

Top GitHub Comments

1reaction

patak-devcommented, Jul 12, 2022

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.

1reaction

brilloutcommented, Jul 12, 2022

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