-
Notifications
You must be signed in to change notification settings - Fork 3
task: Make targets reuse JavaScript builds #265
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
base: trunk
Are you sure you want to change the base?
Conversation
Ideally, the `makefile` serves as the de facto interface for project scripts. This avoids multiple sources of truth and simplifies project onboarding and documentation. Previously, rerunning various `make` targets resulted in rerunning the expensive and slow `make build` target. It's important to ensure the build output exists for many targets, but is often unnecessary to rerun the build when running targets multiple times--e.g., Swift test targets. This introduces a caching mechanism. The `make build` target skips running and relies upon the cache unless one of the following is true. - dist doesn't exist - REFRESH_JS_BUILD is set to true or 1 - build was invoked directly This enables quicker reruns while also ensure the build is always recreated when important to do so--e.g., direct invocations, CI runs, releases. See #253 (comment)
Follow project practice of using the `makefile` as the de facto script interface.
| steps: | ||
| - label: ':react: Build React App' | ||
| command: make build REFRESH_L10N=1 | ||
| command: make build REFRESH_L10N=1 REFRESH_JS_BUILD=1 |
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.
Ensure CI tasks always rebuild the JavaScript to avoid unexpectedly stale builds.
| fi | ||
|
|
||
| make build REFRESH_DEPS=1 REFRESH_L10N=1 STRICT_L10N=1 | ||
| make build REFRESH_DEPS=1 REFRESH_L10N=1 REFRESH_JS_BUILD=1 STRICT_L10N=1 |
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.
Ensure the release script always creates fresh JavaScript builds.
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 existing documentation was formatted via the projects' make format script.
| ```bash | ||
| # Build Swift package | ||
| swift build | ||
| make build-swift-package |
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.
Reinstates directives for Claude to prefer the make targets.
What?
Speed up repeated
maketarget runs that depend upon themake buildtarget.Why?
Address #253 (comment).
Ideally, the
makefileserves as the de facto interface for project scripts. This avoids multiple sources of truth and simplifies project onboarding and documentation.Previously, rerunning various
maketargets resulted in rerunning the expensive and slowmake buildtarget. It's important to ensure the build output exists for many targets, but is often unnecessary to rerun the build when running targets multiple times—e.g., Swift test targets.How?
This introduces a caching mechanism. The
make buildtarget skips running and relies upon the cache unless one of the following is true.distdoesn't existREFRESH_JS_BUILDis set totrueor1buildwas invoked directlyThis enables quicker reruns while also ensure the build is always recreated when important to do so—e.g., direct invocations, CI runs, releases.
Testing Instructions
Run the
make test-swift-packagetarget with/without the following:distdirectoryREFRESH_JS_BUILD=1If the
distexists andREFRESH_JS_BUILDis not enabled, themake buildtarget should be skipped, much like the functionality found in thenum-dependenciesandprep-translationstargets.CI runs and the release script should always refresh the JavaScript build to avoid cryptic or unexpected outcomes.
Accessibility Testing Instructions
N/A, no user-facing changes.
Screenshots or screencast
N/A, no user-facing changes.