@autobusal/providers 1.3.9 → 1.4.0

package/CHANGELOG.md

@@ -4,6 +4,31 @@ All notable changes to `@autobusal/providers` are documented here. This project
 adheres to [Keep a Changelog](https://keepachangelog.com/en/1.1.0/) and
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [1.4.0] - 2026-07-30
+
+### Added
+
+- **Cache-busting on language file requests (`Setup/languages.ts`).** A
+  production report showed the admin panel still displaying raw i18n keys
+  after obtapi's translation JSON was fixed and confirmed correct
+  server-side - even after multiple manual hard-reloads. `Cache-Control:
+  no-cache` on obtapi's side only asks caches to revalidate before reuse,
+  which was not reliable enough against whatever was actually caching
+  (browser and/or an intermediate proxy) in the real deployment. The
+  `loadPath` now appends `?v={{VITE_BUILD_ID}}`, a fresh value baked in at
+  build time by the consuming app's `vite.config.ts` `define` - every
+  rebuild produces a URL nothing in the chain has ever cached, independent
+  of whether that cache actually honors Cache-Control. Falls back to a
+  fixed `'dev'` string if the consumer hasn't defined `VITE_BUILD_ID` yet
+  (no worse than before). **Requires consuming apps to add a
+  `VITE_BUILD_ID` define to `vite.config.ts`** (done for magus and
+  alvavel alongside this release) for the cache-busting to take effect -
+  without it, this version behaves identically to 1.3.9.
+- Companion fix in obtapi: `public/.htaccess` strengthened from
+  `Cache-Control: no-cache` to `no-store, no-cache, must-revalidate,
+  max-age=0` plus `Pragma`/`Expires`, so language JSON is never stored by
+  a compliant cache at all, not just revalidated.
+
 ## [1.3.9] - 2026-07-30
 
 ### Fixed

package/Setup/languages.ts

@@ -6,6 +6,18 @@ export const getLanguage = (defaultLanguage: string): string => (
   localStorage.getItem('language') ?? defaultLanguage
 );
 
+// Cache-busting query param for the language files. `Cache-Control: no-cache`
+// on the obtapi side only asks caches to revalidate before reuse - in
+// practice that was not enough (some browser/proxy along the way kept
+// serving a stale translation file across manual hard-reloads after a
+// deploy). VITE_BUILD_ID is a fresh value baked in at build time by each
+// consuming app's vite.config.ts (`define`), so every rebuild produces a
+// URL that has never been requested before - nothing anywhere in the chain
+// can have a stale cache entry for it, independent of whether that cache
+// respects Cache-Control at all. Falls back to a fixed string for any
+// consumer that hasn't set VITE_BUILD_ID yet (no worse than before).
+const buildId = import.meta.env.VITE_BUILD_ID ?? 'dev';
+
 const languages = (type: string, defaultLanguage: string): void => {
   if (i18next.isInitialized) {
     return;
@@ -22,7 +34,7 @@ const languages = (type: string, defaultLanguage: string): void => {
       fallbackLng: defaultLanguage,
       debug: import.meta.env.DEV,
       backend: {
-        loadPath: `${ import.meta.env.VITE_API_OBT }/languages/{{lng}}/{{ns}}.json`
+        loadPath: `${ import.meta.env.VITE_API_OBT }/languages/{{lng}}/{{ns}}.json?v=${ buildId }`
       },
       ns: type
     });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@autobusal/providers",
-  "version": "1.3.9",
+  "version": "1.4.0",
   "author": "Ferjolt Ozuni",
   "type": "module",
   "main": "index.ts"