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

🏗 Reorganize default gulp task to build extensions after launching server #24138

Merged
merged 1 commit into from Aug 22, 2019
Merged

🏗 Reorganize default gulp task to build extensions after launching server #24138

merged 1 commit into from Aug 22, 2019

Conversation

rsimha
Copy link
Contributor

@rsimha rsimha commented Aug 22, 2019

Today, the default gulp task builds the core runtime and all extensions before starting up its webserver. As the number of extensions has increased, the wait for server startup has become several minutes long.

This PR reorganizes the default gulp task as follows:

  1. Build the core runtime and other default targets
  2. Launch the webserver
  3. Build extensions

With this PR, the wait for webserver startup goes down from a few minutes to ~30 seconds. The --watch and --extensions mechanisms remain unchanged.

Partial fix for #24141

@rsimha rsimha requested a review from cramforce August 22, 2019 05:42
@rsimha rsimha self-assigned this Aug 22, 2019
Copy link
Member

@cramforce cramforce left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. I think this is a good first step and worth committing.

This is what I had in mind as an even better solution:

  • block web server startup by nothing
  • maybe eagerly build core runtime
  • register a URL handler in the web server that does the following:
    • If the path points to a a file we could build
    • build the file now,
    • and when that is done respond with the result
    • unregister the handler and default to standard file serving.
    • in the luxury version, keep the path handler active and block responding when a watch-triggered build is active as well.
  • That way we'd have quick startup and would just lazily build extensions as they are actually requested.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants