I'm looking at how to package a Razor Class Library as a package. I'm building with Vite and using a js file as "entry point". It looks to me as the fact that Vite would create file names like "App_Plugins/MyPackage/dist/en-us-FreAp4rx.js" would facilitate cache-busting for any "sub modules", but have anyone created something that adds a cache buster for the entry point? I mean the first file that is requests, eg. /App_Plugins/MyPackage/dist/my-package.js I thinking about adding a version number or something to the umbraco-package.json file but wanted to check if anyone else have other ideas? Might be good if the core itself added the package version number as cache buster? Just thinking out loud 😄 EDIT: This is reg. v14 😄

Now I may be saying something dumb, but doesn't Umbraco already do this automatically? Perhaps not in local development, but certainly when running in production mode. These are several plugin files that are running in the backoffice for me, also built as RCL and with vite: https://cdn.discordapp.com/attachments/1244567136114966529/1244578603140776007/image.png?ex=66559fa6&is=66544e26&hm=54351164b02f5a26af46765fceb3c36b1a6fd3e7dc3d55ebaf064dacea08c065&

Umbraco cache busts based on its own version and generates the hash based on the files it's including from things like package.manifest (umbraco-package.json) but @Markus Johansson is right it doesn't change if you package updates and the file name doesn't change. In v13 adding a query string broke smidge but in v14 I don't think that happens so you might be able to do that. 🤷‍♂️ Maybe Core could use the package version as a part of the hash and then it would break for each package version?

@Jacob Overgaard do you have any ideas about this? I noticed that the core-stuff has some kind of hash in the URLs?

Yes, we remap the static assets route for the backoffice with a generated hash in the url so the url

/umbraco/backoffice/<hash>/*

leads to the web path

/umbraco/backoffice/*

. You could do something similar in your solution. However, you will have to know the hash when you type out the path in the umbraco-package.json file. I think it would be a good idea if we introduced some sort of way to load extensions with the version number and/or hash for you in the Backoffice client. https://cdn.discordapp.com/attachments/1244567136114966529/1244648435928530944/image.png?ex=6655e0af&is=66548f2f&hm=dee116b79678a14204afd31cec79674d9ec05553ceee79ea48e7886900317b47&

Since you are using Vite, it may be worthwhile looking into this: https://github.com/Eptagone/Vite.AspNetCore

@Jacob Overgaard I agree, if you could append a cache-buster based on the package version that would be fantastic. I guess that the "short term" solution would be to just try to manually add something unique to the URL. I mean, for me it would be enough with just entry points but I guess that it would have to apply to any assets loaded from the umbraco-plugin.json file.

I thought maybe by its usage of the hash, you might be able to refer to your packages hash in some way! There’s a manifest file being built in one of our projects but TBH I don’t know if that’s Vite or this .NET dependency building the manifest file. Sorry if it didn’t help!

@Mark Drake Thanks man! It will work like you say with a submodules that my script loads but the problem here is the "entry point" file, where I tell Umbraco "hey, here is my plugin, please load this javascript file". Since I have to enter a URL to a js-file I would also have to manage cache busting it when a new package release comes out. I was kind of looking for a solution / rasing awareness around this.

Good point. I think we'd do a placeholder so you can decide where it should land up. We already support it for importmaps where you can do

#CACHE_BUSTER#

wherever you like. I think we should be able to do the same for extensions. Maybe even support

#PACKAGE_VERSION#

.

@Jacob Overgaard sounds great! 😄