-
-
Notifications
You must be signed in to change notification settings - Fork 8.6k
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
[DO-NOT-MERGE] RFC: use esbuild to significantly speedup building #4532
Conversation
[V1] Deploy preview failure Built without sensitive environment variables with commit 3825c8e https://app.netlify.com/sites/docusaurus-1/deploys/606282d31ac8060008217b10 |
[V2] Built without sensitive environment variables with commit 654cfb1 |
⚡️ Lighthouse report for the changes in this PR:
Lighthouse ran on https://deploy-preview-4532--docusaurus-2.netlify.app/ |
This comment has been minimized.
This comment has been minimized.
New build size report from github actions. Managed to cut down 1 percent in the generated JS. Size Change: -5.97 kB (-1%) Total Size: 570 kB
ℹ️ View Unchanged
|
@SamChou19815 was wondering if we shouldn't build some kind of plugin system for the build tools (or at least webpack js loader) somehow. There's also this https://github.com/alangpierce/sucrase that reports being very fast, and looks not too hard to adopt. Probably hard though to decouple Docusaurus from Webpack in the short term |
@slorber Yes, I think it might be better to expose the loader customization ability for now. We can probably let user specify their custom loader in docusaurus config? |
options: { | ||
loader: 'tsx', | ||
format: isServer ? 'cjs' : undefined, | ||
target: 'es2017', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe target node12 for isServer would more appropriate?
For browsers, it seems we can't use esbuild directly but it seems there is a way to convert browserlists to esbuild target: evanw/esbuild#121
@@ -3,6 +3,7 @@ | |||
"compilerOptions": { | |||
"incremental": true, | |||
"tsBuildInfoFile": "./lib/.tsbuildinfo", | |||
"module": "esnext", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
make sense, does it also solve a bug related to ESBuild or can we add this in a separate PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't remember the context anymore. I remember it's initially added to fix some issue, but maybe the issue is no longer here. However, I think this change is good anyways since the theme-common package is designed for browser to consume.
Motivation
This PR tries to use esbuild to compile all the JS code (including all the mdx-react produced js code). Since esbuild is written in Go with performance in mind, it results in a much faster build. Locally, the server build takes 1min for each locale without this change, and only 40s with this change.
I plan to keep this PR just about replacing babel and minimizer with esbuild to keep the changes small for now. I will start setup the logic for conditionally using esbuild after the webpack PR is merged.
Have you read the Contributing Guidelines on pull requests?
(Write your answer here.)
Test Plan
CI
Related PRs
Redo of #4487.