A shorter rebuild is useful when the page shows your latest change. This Ionify lab checks one visible result—a border changing from 2px to 6px—while keeping local engine state. Use a disposable, supported app and retain your normal styling packages.
Add an unmistakable rule
In a stylesheet already imported by the app:
.build-lab-card {
border: 2px solid #b77928;
padding: 1rem;
}
Apply the class to an element you can easily find. Build with pnpm exec ionify build and inspect the production output through your normal static preview server.
Now change only the border width to 6px. Build again without deleting the local engine state. Check the element's computed border width in the browser. Record the result, not just the time.
Which styling path did you try, and did the production border reach 6px?
Exercise the real styling path
If your app uses CSS Modules, repeat with a property in an imported module. If it uses a preprocessor or generated utility CSS, make a change that that pipeline must observe. Do not assume the plain-CSS result covers it.
Ionify's public setup describes CSS/CSS Modules support. Sass and Less still require their compiler packages. Tailwind and PostCSS need their normal packages and configuration. Follow the current configuration reference for the version under test.
Optional: record enough to debug
Project / report key:
Stylesheet mechanism:
Exact build command:
Starting state / state retained:
Changed source and value:
Expected computed style:
Actual production computed style:
Engine and styling package versions:
Config files involved:
Was a service worker or browser cache active?
Evidence: redacted screenshot or public reproduction URL
If the style is stale, first confirm the browser is serving the output you just built. Preserve the failure before clearing caches so the reproduction still explains what happened.
The purpose is a reliable edit-to-check loop. No style change needs to become a migration argument; it just needs to reach the app correctly.
Top comments (0)