Show dep optimization progress in the CLI

[NullVoxPopuli]

Description

currently the only way to see depOptimization progress is to run vite with --debug.

This will print something like:

vite:deps Dependencies bundled in 212457.56ms +4m
  vite:deps ✨ using post-scan optimizer result, the scanner found every used dependency +7m
  vite:deps creating _metadata.json in [...]/node_modules/.vite/deps_temp_08f2ea8b +4ms
  vite:deps renaming [...]/node_modules/.vite/deps_temp_08f2ea8b to [...]=node_modules/.vite/deps +6ms
  vite:deps ✨ dependencies optimized +8ms

and trying to visit the app in the URL will break / not-work until this vite:deps phase is done.

Without --debug, there is no way to know when vite is actually ready to serve the app.

Suggested solution

show progress in the terminal to allow folks to know when they can visit their app

Alternative

No response

Additional context

No response

Validations

• [x] Follow our Code of Conduct
• [x] Read the Contributing Guidelines.
• [x] Read the docs.
• [x] Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[hi-ogawa]

trying to visit the app in the URL will break / not-work until this vite:deps phase is done.

I don't think this is expected and at least there should be an automatic full reload after dep optimization to get the app back to proper state. Can you provide a reproduction?

[NullVoxPopuli]

Nay, I'm experiencing this on a 3 million line app.

I have not experienced this in small projects

[hi-ogawa]

So, essentially is the request about enabling vite --debug deps or DEBUG=vite:deps vite by default instead of opt-in debug log?

[NullVoxPopuli]

not really -- that's still a lot of information -- but having a progress bar in the terminal would be helpful -- and the out of / total can increase as imports are discovered

[bluwy]

Nay, I'm experiencing this on a 3 million line app.

I have not experienced this in small projects

I know you're active in open source, but this doesn't make a repro impossible. We're trying to understand the root cause to justify the proposed feature request here, so a repro is important.

Since this relates to prebundling, there must be some dependencies that's probably causing the most slowdown. Is it possible for you to nail that down?

[NullVoxPopuli]

Yeah most of the pre bundling happens from the main entrypoint, which pulls on about 5k modules - all of which gotta go through babel right now - and most of that 5k in in my app - i've started looking at if i can have import analysis only run babel on select files, and fallback to esbuild for everything else, which could hypothetically help a little, since babel is slow, and we know that stuff published to npm shouldn't need additional babeling.

But, the progress bar would be useful even still.

Closest i have to a repro off hand is one i made for the ssl issues that were fixed in 7.2. that repo has a ton of generated modules: https://github.com/NullVoxPopuli/vite-lots-of-module-repro

[NullVoxPopuli]

at the moment, vite says "ready in (under 1s)ms"

which is somewhat a lie if you have optimizeDeps.include set (at all)

[NullVoxPopuli]

that repo has a ton of generated modules

nevermind, it has "no dependencies" 🤔

I may need to generate the files with a bunch of big libraries

at the very least, I'll need:

  optimizeDeps: {
    include: [
      './src/all.js',
    ]
  },

and then

pnpm vite --force

[NullVoxPopuli]

so, with a small repo, I can nearly get to a 1s delay between "vite ready" and being able to load a page:

  VITE v7.1.7  ready in 204 ms

  ➜  Local:   https://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help
  vite:deps ✨ static imports crawl ended +51ms
  vite:deps Crawling dependencies using entries:
  vite:deps   <repo>/index.html +0ms
  vite:deps Scan completed in 188.19ms: no dependencies found +109ms
  vite:deps creating package.json in <repo>/node_modules/.vite/deps_temp_64cdc9dd +248ms
  vite:deps Dependencies bundled in 777.22ms +778ms
  vite:deps ✨ using post-scan optimizer result, the scanner found every used dependency +916ms

This delta is what should have a progress bar

[NullVoxPopuli]

oh! I got it to 3.4s!

Branch here: https://github.com/NullVoxPopuli/vite-lots-of-module-repro/tree/vite-issue-21149

git clone [email protected]:NullVoxPopuli/vite-lots-of-module-repro.git
cd vite-lots-of-module-repro
git checkout vite-issue-21149
pnpm install
pnpm vite --force --debug

Output:

# don't open a browser
VITE v7.2.4  ready in 567 ms
...
vite:deps Dependencies bundled in 3627.00ms +4s
# ^ browser would not be served until this is done 
#   -- now imagen this takes a couple minutes haha

[hlongc]

Hi! 👋

I've created a PR to address this issue: #21167

I've added user-friendly progress messages that show:

• When dependency scanning starts
• How many dependencies are being optimized
• When optimization completes with timing info

Looking forward to your feedback! 😊

[bluwy]

Got some time to look at the repro and I can see it's also slower for me. Not sure if it matters for your app, but you should use optimizeDeps.entries: ['./src/all.js'] (add any relevant html entrypoints if needed for crawling) instead of optimizeDeps.include, since the latter means bundling src/all.js entirely with esbuild. We only want to crawl and bundle the crawled files' dependencies. Some stats on my machine:

	Scan time	Bundle time
optimizeDeps.include	256ms	6000ms
optimizeDeps.entries	3981ms	1358ms

If you do have optimizeDeps.include misconfigured, you can switch to this and offload the timing to the scanner. The scanning time can be easily bypassed by manually specifying the deps in optimizeDeps.include yourself, and then set optimizeDeps.entries to an empty array.

---

If the config is right, I guess we can consider adding information of the prebundling progress. The reason I'm a bit hesitant with adding a progress bar is because rendering it requires continuous updates, and it can interfere with logs from plugins or debug logs when that happens. They're ways around this I suppose by delay showing it, or only log a line about "taking longer than usual".

Also, there's not a lot of progress information we can show, especially for the esbuild bundling. We pass the dependency entrypoints to esbuild, and then wait for its output. Hooking to the esbuild bundling hooks to log progress would probably only slow it down.

I'd like to hear what others on the team thinks about this request too.

[NullVoxPopuli]

Yeah, optimizing this specific example would side step the point. I just wanted a slower to boot app. My real app at work is over 55MB of source (excluding the hundreds of dependencies) - harder to reproduce this in open source.

I appreciate you taking a look though!

But also!, there may be a better progress indicator we can use that doesn't involve vite changing anything, but it uses the performance APIs and is all in-browser. I'll post it tomorrow