Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: scan free dev server #8319

Merged
merged 68 commits into from
May 27, 2022
Merged

feat: scan free dev server #8319

merged 68 commits into from
May 27, 2022

Conversation

patak-dev
Copy link
Member

@patak-dev patak-dev commented May 25, 2022

Description

Depends on merging:

#8280 doesn't perform a scanning phase during build, and directly lets rollup process all user code first before running the optimizer. Once rollup is idle because the only pending promises are the load hooks for optimized deps, then a single optimization run is issued. So basically we scanned the whole code base with rollup and the real plugins. For the user, the only diff is that for the first run, the deps will take a bit longer than the rest, eliminating scanning from the pipeline seems like a good tradeoff.

This PR does the same during dev, since we are eagerly processing everything, it ends up being quite similar. Even the same idle detection code should work if at one point we implement this.load({ id }) in PluginContainer (right now I added the registering of ids on import analysis while doing the eager processing of static imports).

Edit: there is an option marked as experimental to enable back the scanner during dev optimizeDeps.devScan.

Open questions:

  • Should we also crawl non-critical dynamic imports? We were talking with @antfu that maybe we should only block optimization processing for optimizedDeps.entries manually configured. This would be a way to let users choose between potentially needing a full reload after and taking more time on cold start (projects like Laddle may choose the former)
  • After this PR, scanning is only used for SSR externals and we are going to remove that in SSR builds. We may need to keep the scanning code around for SSR CJS build externals calculation, but by default it won't be used at all. Having the full scan code only for the externals heuristics seems very heavy though, so I hope we could find a way to remove it. But maybe it isn't bad to keep it around as an opt-in during v3 so projects than don't work well with a scan free dev server can still fallback to it.

What is the purpose of this pull request?

  • Bug fix
  • New Feature
  • Documentation update
  • Other

@patak-dev patak-dev changed the base branch from main to feat/non-blocking-esbuild-optimization-at-built-time May 25, 2022 09:48
Co-authored-by: Evan You <yyx990803@gmail.com>
@patak-dev patak-dev added this to the 3.0 milestone May 25, 2022
Base automatically changed from feat/non-blocking-esbuild-optimization-at-built-time to main May 26, 2022 16:45
@patak-dev
Copy link
Member Author

Let's merge this one so we can release a new alpha with it soon.

@patak-dev patak-dev merged commit 3f742b6 into main May 27, 2022
@patak-dev patak-dev deleted the feat/scan-free-dev-server branch May 27, 2022 14:28
@patak-dev patak-dev mentioned this pull request Jun 7, 2022
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3-significant High priority enhancement (priority)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants