Conditionally skip frontend build tasks

[vishal423]

Closes #13796

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• jhipster-online was updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (bellow reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[atomfrede]

Are you building the checksum across the input file? Asking because while evaluating our build scans the resulting index.html contains the buildtimestamp for cache busting of translations files. So maybe this might not be "correct", although I would say for development it is fine in case the build timestamp is "outdated".

[vishal423]

Not sure I quite get your question. The checksums are calculated over a set of frontend input source files including i18 translations. As long as there is a change in one of the input files (including package.json), we shall execute the node build steps. Here, we are not concerned with generated output files that might contain a build timestamp for cache bursting.

I believe you are looking into the 2nd OR condition. That handles a special case when the user first does the frontend build and later tries to run a maven build (first time). In that scenario, to avoid another frontend build, we check if the build output contains the input.html.

[vishal423]

It seems @pascalgrimaud is a little occupied. @jhipster/developers, anyone else wants to try out the change and review? I think it greatly simplifies the build time and improves the overall developer experience.

[atomfrede]

Not sure I quite get your question. The checksums are calculated over a set of frontend input source files including i18 translations. As long as there is a change in one of the input files (including package.json), we shall execute the node build steps. Here, we are not concerned with generated output files that might contain a build timestamp for cache bursting.

I believe you are looking into the 2nd OR condition. That handles a special case when the user first does the frontend build and later tries to run a maven build (first time). In that scenario, to avoid another frontend build, we check if the build output contains the input.html.

A little had to describe, but I think your change mimics the gradle change detection which is great. The build timestamp is not relevant if the i18n files are also in the checksum, so it's fine. I will give it try today.

[pascalgrimaud]

Yes sorry @vishal423 : I don't have enough time these last weeks.
If someone can help to review and test it, it would be really welcome.
Otherwise, I'll do my best when possible

[mraible]

I tried it today:

• 1st build (after downloading everything): 53s
• 2nd build: 15s

Looks good!

FWIW, I used my jhipster7-demo project to test.

[atomfrede]

Nice work! Works very well.

First build 58s
Second build 18s 🚀

@vishal423 Don't forget to claim the bounty, well deserved!

[mshima]

Sorry for the late review.
This will generate a development jar without frontend.

rm -rf target
./mvnw -P-webapp compile
./mvnw package

This will start a development backend with production frontend.

rm -rf target
./mvnw -Pprod compile
./mvnw

IMO we should rely on webpack 5 cache.

[vishal423]

@mshima , Thanks for review. I had the first issue in mind and will create a PR for that.

[mshima]

Should include configurations that can change generated webapp:

• webpack/*
• (.)postcssrc.js ? too much?

When executing with production profile mvnw should delete checksums.

[vishal423]

Bounty claimed https://opencollective.com/generator-jhipster/expenses/40680

[jdubois]

Awesome work @vishal423 !!