[Webpack] The numeric prefix for cache busting in URLs to static resources does not change even if plugin code changes

[tsullivan]

Files such as JS files are imported via webpack and become part of your plugin bundle(s). That way, the resource URL has a cache-busting random number in the URL. (e.g the 39000 in localhost:5601/39000/bundles/plugin/myplugin/myplugin.plugin.js)

However, after the "refresh" of the plugin, the cache busting key stays the same, so the browser uses the dirty cache instead of sending a request to refresh the code.

From: https://discuss.elastic.co/t/custom-kibana-plugins-will-not-update-due-to-client-side-resource-caching/267207

[elasticmachine]

Pinging @elastic/kibana-operations (Team:Operations)

[spalger]

This number isn't random, it's the Kibana build number. The main issue is that assets from installed plugins are cached for 1 year based on the Kibana build number, which is assumed to change whenever the source does, but plugins can be installed and updated within the lifetime of a single Kibana version.

Sounds like we should probably include version information from plugins in the URL serving plugin assets. As a workaround users should be able to bump the build number in the package.json file to cache bust all assets when they update a plugin.

IIRC we have the ability to set a unique baseUrl for each plugin bundle based on the way things work under the hood, but getting the right version numbers to include in the URL so that caches are still long-lived but properly invalidated when things update might be tricky...

cc @elastic/kibana-core?

[pgayvallet]

Yea, our production build-number based cache / url prefix wasn't conceived for 3rd party plugins...

I guess that for 3rd party plugins, using the version field from the plugin's kibana.json manifest would make the most sense. Of course, for our plugins, this version field is hardcoded, so we would have to dissociate 3rd party plugins from internal plugins (which we don't atm).

I guess also using /{buildNum}/{pluginVersion} as prefix instead of just /{buildNum} would address both kind of plugins. I don't think this would have negative impact on the long-lived cache in production, wdyt @spalger?

[spalger]

I guess also using /{buildNum}/{pluginVersion} as prefix instead of just /{buildNum} would address both kind of plugins.

Sounds like a good idea to me