Cache-busting reikt nu ook tot wat de modules zelf ophalen (shaer-724)
De bootstrap hing al ?v= aan elke module die hij zelf laadt. Twee soorten
paden ontsnapten daaraan, en /assets wordt buiten ontwikkeling een jaar
gecachet:
een import BINNEN een module is relatief, en zo\x27n specifier erft de
query niet: ./lib.js naast post.js?v=63 wordt gewoon
/assets/js/mod/lib.js. Elf modules importeren lib.js zo, en juist dat
bestand is gedeeld -- een fout erin overleefde elke MOD_V-bump.
een vendorbestand dat een module zelf ophaalt. read.js deed het goed met
?v=VENDOR_V; lib.js (mijn eigen import van gisteren) en de twee
cropper-verwijzingen in post-edit deden het niet.
Een importmap in de head lost het eerste op zonder die elf imports aan te
raken: hij vertaalt de opgeloste URL naar zijn geversioneerde vorm. MOD_V
staat daarvoor nu als EJS-variabele bovenaan de shell, zodat de importmap
en de bootstrap niet twee nummers kunnen worden. VENDOR_V staat in lib.js
en wordt door read.js en post-edit gedeeld, om dezelfde reden.
Drie toetsen die de REGEL bewaken en niet deze ene plek: elke relatieve
import tussen modules heeft een ingang in de importmap, elk vendorpad
draagt een versie, en de twee nummers zijn er een. Tegenbewijs: haal de
ingang weg of de versie eraf en precies die toets valt.
Volle suite 1248 groen.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
