-
Notifications
You must be signed in to change notification settings - Fork 14
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
Allow faster frontend builds #351
Allow faster frontend builds #351
Conversation
New script to build faster, using `BUILDSCRIPT=:fast` - E.g. building locally: `BUILDSCRIPT=:fast make build-frontend` - E.g. building image: `BUILDSCRIPT=:fast make images` The drawback is potentially not catching errors related to using dependencies (e.g. patternfly ...); that's the reason why I prefer to keep the default build as a "full compiling" build. But these new targets can save developer's time when doing frequent iterative changes. In any case, if a compile error is uncaught by the developer, it should be caught by the CI build, which is unchanged. On my machine, TS compilation is 5x faster (~100s => ~20s)
Codecov Report
@@ Coverage Diff @@
## main #351 +/- ##
==========================================
- Coverage 58.83% 57.92% -0.91%
==========================================
Files 121 150 +29
Lines 4912 6665 +1753
Branches 797 797
==========================================
+ Hits 2890 3861 +971
- Misses 1894 2588 +694
- Partials 128 216 +88
Flags with carried forward coverage won't be shown. Click here to find out more. |
From what I see in the ts-node usage the This The logging plugin that also use ts-node doesn't add this -I option: Maybe it's simply not needed anymore ? |
@jpinsonneau hmm my first guess was that ignoring |
web/package.json
Outdated
@@ -5,12 +5,14 @@ | |||
"scripts": { | |||
"clean": "rm -rf ./dist", | |||
"build": "npm run clean && NODE_ENV=production npm run ts-node ./node_modules/.bin/webpack", | |||
"build:fast": "npm run ts-node-fast ./node_modules/.bin/webpack", |
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.
actually, what makes it faster is perhaps more the removal of npm run clean && NODE_ENV=production
than the ts-node
options ....
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.
yes, the NODE_ENV=production
part makes the difference:
21677ms
without it51624ms
with it
Using npm run clean
doesn't change a lot the total time (around 2000ms) so I would suggest to keep it as it ensure the dist folder is recreated from scratch and avoid any cached bundle / manifest / asset
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.
going deeper the production
is slower mainly because of module.exports.optimization.minimize
- Ignoring node_module with ts-node (default) makes sense for all builds, not just fast build - Use :dev instead of :fast then, since the only difference with normal builds is actually the NODE_ENV=production var - Remove .git from the dockerfile to avoid rebuilding all after any git change (e.g. git fetch) - As a consequence of the Docker build being unaware of git, need to pass some info (version from git) as a docker argument (LDFLAGS)
@jpinsonneau so I did that, removed the |
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.
LGTM thanks @jotak 🥳
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jotak The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
New script to build faster, using
BUILDSCRIPT=:fast
BUILDSCRIPT=:fast make build-frontend
BUILDSCRIPT=:fast make images
The drawback is potentially not catching errors related to using dependencies (e.g. patternfly ...); that's the reason why I prefer to keep the default build as a "full compiling" build. But these new targets can save developer's time when doing frequent iterative changes.
In any case, if a compile error is uncaught by the developer, it should be caught by the CI build, which is unchanged.
On my machine, TS compilation is 5x faster (~100s => ~20s)