prebuild Order: Update Generated Values Before Validation
What you’ll learn
- How to distinguish an outdated reading-time value from an incorrect processing order
- The roles of updates before content review and checks before a build
- Which values can be updated automatically and how to preserve update-before-validation order
An Outdated Reading Time That Stopped the Build Process
A build turns articles and programs into files for serving a website. On this site, reading time calculated from the article length could remain outdated, causing a check to stop the process before the build. learning_time is the article setting that stores that reading time.
I expected that correcting the value once would let the next run succeed, but changing the text brought the same problem back. The cause was not an incorrect manual entry: the value was being checked before it was updated. Normalization—bringing values into the agreed calculation rules and format—needed to run first.
This article looks back at how I separated updates and validation on this site. It distinguishes fixing an individual article’s value from changing the processing order to prevent the same failure recurring.
Updating Reading Time Versus Checking It
This site uses Astro and Starlight to create files for serving and Vercel to publish them. An apparent build failure could actually occur in prebuild, the preparation and validation stage that runs before the build itself.
The reading-time process has a --write operation that calculates the value from the text and writes it back, and a --check operation that compares the current value with the calculation. Checking alone does not fix an old value. If the text grows and the reading time has not been recalculated, running only the check stops the process.
The fix was to guarantee update the value → validate the updated value in both dev:check, the normal local checks, and prebuild, the pre-build checks. Differences that have a prescribed automatic fix are corrected first; validation reports the remaining problems.
Normalization Before Content Review and the Role of Later Checks
If reading time changes only just before a build, machine-generated changes can appear during content review. In the normal writing and update workflow, settle reading time once the Japanese learning text and English translation are ready, separating prose review from value adjustments.
This project has an operation that updates reading time from the text length. It updates and preserves the following information.
| Item | What is updated or preserved |
|---|---|
| Japanese reading time | Calculated at about 300 effective characters per minute |
| English reading time | Calculated at about 130 words per minute |
| Displayed reading time | Minimum five minutes, rounded to five-minute increments |
| Hands-on time | Existing value preserved, without recalculating it from text length |
These are this site’s calculation rules. They are not universal defaults for sites that estimate reading time differently.
Edits during review or translation can change the text length again. The writing-stage step settles generated changes before review; dev:check and prebuild are safety nets for skipped updates and drift after later edits.
Automatically Checking the Update and Validation Order
Changing the configuration once is not enough if a later edit removes normalization or puts validation first. This site checks the following conditions as well as the resulting values:
- Both normal local checks and pre-build checks include a value-update operation
- An operation validates the updated value
- Updating runs before validation
Preventing recurrence means preserving that order through later changes, not only repairing one article. Correct ordering still does not establish whether the calculation rule is suitable or the prose is accurate.
Separating Local Checks, a Local Build, and Publication Results
Three different results need to be checked:
- Normal validation: whether reading-time, link, and article-setting issues have been resolved
- Local build: whether files for serving can be created locally at an approved stage
- Publication result: whether Vercel’s publishing process succeeds and the page can actually be opened
This project requires explicit user approval before running npm run build. Normal local validation comes first; a build is checked separately when needed. A successful local build and successful publication are also treated as different results.
Summary: Check the Order of Value Updates and Validation Too
Correcting an old reading-time value once did not prevent recurrence. Settling the value before content review and retaining update-before-validation order in later checks separates generated-value changes from prose review. The order itself also becomes an automated check target.
Automatic updates should be limited to values with a prescribed rule that produces the same result. Normalizing factual errors or content requiring human judgment would hide the problem. This design depends on distinguishing value updates, content review, and successful publication.