https://discord.umbraco.com
Join Discord
Cache invalidation for import maps
# package-development
m
I Have a question around shipping packages with import maps, how does one handle cache invalidation? My current approach has been to append the version to the entry point js file, but if I was to include serveral import maps in the 
umbraco-package.json
ifle as well it feels like a lot of places where these would have to be appended.
w
Is this for building/bundling/shipping something? If so if its tedious job to do, could a Powershell script help you out to append the cache bust version querystring or something ?!
If its for during your development cycle then - I would imagine its something similar but done with Node script land or some kind of Vite plugin you write yourself to add it in
m
I do have a powershell-script that will append the package version as a cache buster ?v1231 kind of style for the package entry point. I just found that importmaps support a Cache Buster Token that will be replaced at runtime, this kind of solves the problem for me I think.
Copy code
{
  "$schema": "../../../umbraco-package-schema.json",
  ....
  "importmap": {
    "imports": {
      "@my-package/base-classes": "/App_Plugins/myPackage/dist/base-classes.js?v%CACHE_BUSTER%"
    }
  }
}
w
Is that an Umbraco thing or a native browser thing ?
m
It a Umbraco-thing, they do a simple string replace, they have some magic for the cache-busting stuff where they are requesting assets with a hash /umbraco/backoffice/{hashBasedOnUmbracoVersion}/{pathToAsset} Then they have a AddRewrite that basically redirects to /umbraco/backoffice/{pathToAsset} and serve files from the RCL
I have not looked closely at how the hash is created but if it does not take all package versions into account it would not work for a package since it might not change when a package is updated.
Nope. In debug mode it will regenerate the hash on each startup but in production mode it uses the umbraco version to generate the hash. So if we use it for a package this hash and a user upgrades the package it would not change the hash in production unless Umbraco it self is also upgraded.
It feels like there should be something in the core for this so that each and every package developer dont't have to come up with their own solution.
w
Totally agree - but not yet at stage of importmaps with what I'm doing
Anything that we all need or could benefit from seems to be good shout to get into core
m
I created an issue about the hash, but to be fair - it's probably a bigger discussion to be had. https://github.com/umbraco/Umbraco-CMS/issues/16893
w
Watching the issue to follow along....
m
True, I think that the fact that I would like to ship nu base classes for other developers to use makes the build process very complicated - for packages like "The Dashboard" it's really quite stright forward.
w
Yeh for most packages its probably fine
Its just when you get into the territoary that you have your own extension types that can then in turn extend your extension really
m
I guess that it's not super common but it would still be nice.
I'll make sure to share any findings 😄
4 Views
PreviousNext
Powered by

Umbraco

A hub and casual space for you to interact with fellow community members and learn more about Umbraco!

Powered by