task: Make targets reuse JavaScript builds#265
Merged
Conversation
dcalhoun
commented
Dec 19, 2025
| steps: | ||
| - label: ':react: Build React App' | ||
| command: make build REFRESH_L10N=1 | ||
| command: make build REFRESH_L10N=1 REFRESH_JS_BUILD=1 |
Member
Author
There was a problem hiding this comment.
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 |
Member
Author
There was a problem hiding this comment.
Ensure the release script always creates fresh JavaScript builds.
Member
Author
There was a problem hiding this comment.
This existing documentation was formatted via the projects' make format script.
| ```bash | ||
| # Build Swift package | ||
| swift build | ||
| make build-swift-package |
Member
Author
There was a problem hiding this comment.
Reinstates directives for Claude to prefer the make targets.
Member
Author
|
@jkmassel publishing this as a friendly reminder of this pull request review. This optimizes existing project scripts, so it is definitely not a priority, but commenting nonetheless. Let me know if I can provide any clarifications. Thank you! 🙇🏻♂️ |
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.
2f0ae42 to
bc83582
Compare
jkmassel
approved these changes
Jan 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.