fix: optimizeDeps.entries default ignore paths

[patak-dev]

Description

Fix #5131
Fix #2599

• Remove __tests__ from the ignore list if optimizeDeps.entries is specified
• Add coverage to the ignore list if optimizeDeps.entries is not explicit
• Document that you can use ! to ignore certain folders or patterns: mrmlnc/fast-glob#how-to-exclude-directory-from-reading

Ping @tajo, @IanVS, @Akryum @edikdeisling, @JessicaSachs

Should we add other common folders? #2599 mentions cypress-coverage for example.

Additional context

An interesting issue here is that adding a lot of entries to be scanned may have a big impact on cold start, even now that the scanning is non-blocking, we still need to finish it before being able to respond to dependencies requests.
@tajo tried it out in Ladle and got:

• cold start takes 30s when all stories are in entries and all deps prebundled
• 5s without entries

@JessicaSachs so for Cypress, you may need to choose between increasing cold start or being able to show something to the user and perform some reloads when finding missing deps.

One option for the future, we could add a new optimizeDeps.lazyEntries. The entries marked as lazy will be scanned but not pre-bundled and they will be added once the first missing dependency is found. So at least we only suffer from one full-reload on cold start, keeping the first load fast enough. For cypress, this may not be a good idea since every test may need to run, but for Storybook, Ladle, Historie this may be a good compromise.

---

What is the purpose of this pull request?

• Bug fix
• New Feature
• Documentation update
• Other

[tajo]

So at least we only suffer from one full-reload on cold start

We can easily add the default story into entries and all others into lazyEntries so there would be no reloads.

[patak-dev]

We can easily add the default story into entries and all others into lazyEntries so there would be no reloads.

Yes, this is what I'm thinking too. I'll try to do a PR for this at one point. To really work well I think we should not start the lazy scan until the initial processing for all modules of the app is done, if not we would be consuming resources and hurting the initial load time. We need to check how to start the scan once Vite is idle

[bluwy]

I'm not sure how lazyEntries will be implemented, but it sounds like it would then incur double bundling, and potentially needing another page reload. Not really sure if this extra complexity is needed, but I think the real issue is why it's taking 30s for esbuild to bundle things. Perhaps some deps are bundled when not needed?

[tajo]

I think the real issue is why it's taking 30s for esbuild to bundle things

I think it's the combination of a large project and using a custom (JS) esbuild plugin to remove flow types. Without this plugin it finishes much quicker (<10s).

potentially needing another page reload

Why does Vite need to do full page reloads anyway?

[patak-dev]

Why does Vite need to do full page reloads anyway?

When Vite optimizes dependencies it passes all of them to esbuild together, as there could be common parts and interdependencies. This is why you will see chunk-xxxxxxxx.js in .vite/deps. If we find new dependencies, we need to re-optimize the old ones + the new ones and the old deps and common chunks could change. If they change, we need a full page reload because if we give these back to the browser we could get duplicated state (think in Vue and React internal state). After 2.9, we are now checking if the old deps changed so we can avoid some full page reload (for example if you have vue optimized, then add gsap that has nothing in common, there is no need to reload)

About lazyEntries, I'm also still unsure if the complexity will justify the feature. But I think it could be interesting to explore this and see. We talked with Anthony that it would be interesting to avoid optimization ES deps that only have a few modules... we need to do so for lodash for example, but if the dep is a single JS file, then it is better to avoid it. And if we have fewer dependencies in the optimization pool, we could avoid more page reloads as there are fewer chances of old deps getting outdated. So maybe in the future, lazyEntries could become more interesting... at the same time, if there are fewer page reloads, we could just let Vite discover deps as it goes without the complex scanning.