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
Build optimization #255
Comments
Discussion about leveraging Bud's Svelte compiler API: livebud/bud#353 |
I'm working on inserting Gopack directly into the Svelte compilation step so it can update the import paths to be ESM ready before they are ever written to the filesystem. This will make builds faster, the reduction of read/writes alone should cut ~200ms from a basic site. An advantage of doing this is we no longer would need to follow imports recursively and resolved them because every single Svelte file (even core svelte files) goes through our compiler and would get resolved at this step. The challenge I'm running into is that when running Gopack on the built "public/spa" output, we're actually going the extra step and verifying the that import paths actually are resolvable on the FS, or else we throw an error. Running Gopack directly on the layouts source files causes this check to thrown tons of errors like:
We could just remove this check and folks would hit the issue in the browser when it can't import, but it does seem less intuitive that way (you'd have to realize hydration failed, then chase down console errors). Another consideration I was removing the Build times with Gopack read/write
Build times inserting Gopack into compileSvelte
|
WIP Bud Compiler: abfbe95 |
The biggest bottleneck currently is compiling components in V8. We're just using one giant VM for this, which makes builds very slow for larger sites and seems to have a memory leak that can timeout once you have a couple of thousand pages. It would be nice to make this process more consistent in general.
The initial issue on concurrent build steps has some interesting suggestions: #26
There are other smaller things that we could do to be more efficient as well. Originally posted in #191:
The text was updated successfully, but these errors were encountered: