-
Notifications
You must be signed in to change notification settings - Fork 572
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
chore: speed up local dev #686
Conversation
as per kulshekhar/ts-jest#259 (comment) using maxWorkers: 1 ends up being faster
size-limit report 📦
|
Codecov Report
@@ Coverage Diff @@
## main #686 +/- ##
==========================================
+ Coverage 75.45% 75.83% +0.38%
==========================================
Files 47 47
Lines 1617 1758 +141
Branches 295 326 +31
==========================================
+ Hits 1220 1333 +113
- Misses 368 397 +29
+ Partials 29 28 -1
Continue to review full report at Codecov.
|
ScreenshotsResult
Details
|
@eh-am |
62d0385
to
75226ed
Compare
…peed-up-local-dev
.sync( | ||
process.env.NODE_ENV === 'production' | ||
? './webapp/templates/*.html' | ||
: './webapp/templates/index.html' | ||
) |
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.
process.env.NODE_ENV isn't really reliable, we could use
https://webpack.js.org/configuration/mode/#mode-none instead
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.
Does this mean in dev mode you won't be able to test other pages? I understand the rationale, but I think this might be confusing when we do want to edit those pages.
It looks like the only thing we do with HtmlWebpackPlugin
is this <%= webpack.hash %>
Interpolation, and 215ms to do some string replacements is still very very slow imo.
Maybe we could git rid of HtmlWebpackPlugin altogether and instead export webpack.hash
to some sort of a file, and then on the go side we would read this file each time we need to render a page and do interpolation via go templates?
I'm not sure how this would work with things like livereload, though.
@eh-am What do you think?
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.
I guess I just remembered we also wanted to get rid of templating on the go side, I guess it would be better to just talk about it on a call.
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.
but I think this might be confusing when we do want to edit those pages.
100% agree, I hope to get rid of this "optimization" soon.
and 215ms to do some string replacements is still very very slow imo.
I read on the webpack docs that stuff like hash isn't very good for production. I didn't profile but I trust them (actually I did but couldn't pin point to the exact problem). I guess we can just not hash for dev? Unless HMR use it for refreshing somehow, but we don't have it so it's a problem for the future.
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.
This is awesome! I thought if you want to use esbuild
you have to ditch webpack
, this is a good middleground.
This also speeds up docker builds (2x improvement for make assets-release
step on my machine) which I'm very happy about.
I left a comment about the html pages, but I'm going to merge this one anyway.
* fix type errors * chore: speed up tests as per kulshekhar/ts-jest#259 (comment) using maxWorkers: 1 ends up being faster * set typescript to only build the webapp/javascript dir * use a specific tsconfig just for linting * speed up tests * lint test files as well * use esbuild * optimize local refresh by only building the index page * print to stderr from webpack to make it easier to save stats * inject livereload script to index.html * fix prod build by enabling ts-jest
maxWorkers=1
as per Speed up performance massively with --maxWorkers=1 kulshekhar/ts-jest#1044includes
to only care about the webapptsconfig
for tests where we manually set whichtypes
are requiredesbuild
instead of babelwebpack-livereload-plugin
to add a livereload server to the html files served by go (removing the need for the double server shenanigans)index.html
since that's the most common case (see webapp/README.md for more info)Local build
Before
After
Tests
Before
After
But the biggest improvement seems to be when running tests with
--watch
.Before
After
Prod Build
Before
After