To champion the lower end Umbraco install… not all have media in blob storage and might also have other disk persisted stores, vanilla js packages and not even a CI/CD deployment process.. , but I understand the sentiment..
There is probably a sweet spot.. of I didn’t update any packages so npm build just wasn’t required for this deployment. (again prob one man/small team deployment mentality)
( npm install… when I have 10+ package extension projects in the solution takes ages.)
Maybe I’m still not accepting that Umbraco isn’t the unzip and deploy a set of files, add a package or two.. and that’s it as a developer/editor. I’d use the backoffice (not even need an IDE) without having any of these considerations
Would FileIO/the computational hash cause issues there, especially when that happens for each pacakge on every backoffice url refresh? though no need to restart the app on entrypoint change.
yeah I’m not shipping packages I’m consuming packages where the entrypoint is stale, so can’t find the now updated component hashed files. (this looked suspiciously like the case with umbracoForms.. but that’s hearsay on my behalf and a forms updated now and no longer the case)
I understand the whole “lower end” point, but selective deletion at deploy has been a necessity for working with .NET since forever, and is supported in all the tooling for deploying .NET whether you’re using CI/CD or not.
Sure, you might get away with not clearing files and constantly deploying Umbraco on top of itself, and plenty do, but you’re bound to run in to problems with that approach sooner or later (luckily there’s always been a friendly forum to post the question when files get locked or deprecated DLLs are left hanging around on the server, or filename-casing change breaks something )
IIRC manifests are only loaded once at boot anyway, but the actual hashing could be lazy/eager + cached.
Selective deletion, think that’s what I was implying over the nuke everything
In the past we have generated a .ps1 script from the repo release diff for batch deletions.. and deploy that with the ci/cd. (using the kudu rest api for azure, making sure to also add an app_offline.htm to unlock dlls etc..)
Having hit this recently the backoffice appears to call the load manifest private/public management api endpoints every url hit.. maybe in the move to a reactive backoffice.. and potentially package addition without recycle (if it’s just frontent lit stuff)?
(previously with smidge/cdf it was a bundle creation at statup though)
but yeah your point on the friendly community.. (hence this dialogue which is much appreciated as its made me reconsider plenty of things )
and a forms updated now and no longer the case)
)
(hence this dialogue which is much appreciated as its made me reconsider plenty of things 
)