Version pinning versus CSS custom properties for safe Bulma upgrades with legacy browser constraint
0 reputation · 08 Jan 2025, 18:22 UTC
0 reputation · 08 Jan 2025, 18:22 UTC
A design goal is to recover from a failed Bulma upgrade without changing HTML markup. Two documented approaches are relevant for this constraint.
One approach is to pin Bulma to a specific version in package.json or the CDN link and revert by reinstalling the previous version. The other approach is to rely on Bulma’s CSS custom properties introduced from version 0.9.0, which allow runtime theming by updating variable values without recompilation.
The constraint is the need to keep the upgrade safe while preserving compatibility with environments that do not support CSS custom properties, and avoiding reliance on a correctly configured Sass build pipeline for variable overrides.
Which approach provides a documented rollback path when an upstream change alters component appearance? Does the presence of CSS custom properties from 0.9.0 change the need to pin the core version for visual stability? How do version-pinned CSS and runtime custom property overrides interact when both are used together?
30775 reputation · 09 Jan 2025, 00:22 UTC
Version pinning provides the documented rollback path for recovering from a failed Bulma upgrade without changing HTML markup. CSS custom properties (introduced in Bulma 0.9.0) do not replace the need to pin the core version for visual stability, and they only add runtime theming on top of the pinned CSS when the browser supports them.
package.json, lockfile, or a fixed CDN URL lets you reinstall that version to revert any upstream visual change.--primary) that can be overridden at runtime via :root; this does not undo layout, spacing, or selector changes made in a new release."bulma": "0.8.0") in your dependency manager or use a versioned CDN URL like https://cdn.jsdelivr.net/npm/bulma@0.8.0/css/bulma.min.css.:root block with your variable overrides after the Bulma stylesheet.Missing diagnostic detail: Please confirm whether the specific legacy browsers you must support lack CSS custom property support. If they do support them, the custom‑property theming approach can be used alongside pinning, but pinning remains required for visual stability.
Use comments to ask for clarification. Post a solution as an answer.
3,900 reputation · 09 Jan 2025, 00:54 UTC
One clarification worth adding to the pinning strategy: writing "bulma": "^0.9.4" in package.json is not pinning. The caret range lets a fresh npm install resolve to a newer minor release, so a rollback attempt can silently reinstall the broken version. Use an exact version ("bulma": "0.9.4") and commit the lockfile, since the lockfile is what actually records the resolved artifact.
The same applies to CDN links: an unversioned or major-version URL like bulma@0.9/css/bulma.min.css floats upstream. Only a fully versioned URL is revertible.
On the interaction question, cascade order matters: the :root override block must load after the pinned Bulma stylesheet, and it only affects properties that version actually defines — so an override written against 0.9.x variables becomes a no-op if you roll back to 0.8.x. Worth verifying overrides against your pinned floor version, not just the latest.