Provide cache buster query string on imports

So we have the items in the import map generated in \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\JsComponent::renderComponent.

Then we have a lot of JS files included in libraries (i.e. in experience_builder.libraries.yml) where the version gets appended from the library definition, but we never update those, and it's not even feasible for xb-ui as that gets recompiled and updated constantly. How are those usually handled? I think I've seen it before that a hash was added to the filename by the JS bundler, and the filename was read in hook_library_info_alter().

(trying to categorize this, not sure what is the best match, assuming Page builder)

If I understood this, most of the issues come from js components?
Adding a cache buster query there from AssetQueryStringInterface.
Wondering if we could use the component version though.

Then we have a lot of JS files included in libraries (i.e. in experience_builder.libraries.yml) where the version gets appended from the library definition, but we never update those, and it's not even feasible for xb-ui as that gets recompiled and updated constantly. How are those usually handled? I think I've seen it before that a hash was added to the filename by the JS bundler, and the filename was read in hook_library_info_alter().

I see 2 options here:

1) KISS, just remove version, and Drupal will handle it using the same AssetQueryStringInterface that uses for the rest of assets.
2) hook_library_info_alter reading ui/package.json, which we should keep in sync on release numbers.

Needs feedback on direction.

+1 for keeping it simple in the first instance

FWIW we could also configure vite to include hash in filenames https://rollupjs.org/configuration-options/#output-entryfilenames
That's something we do on client projects

We now use the package.json version (or a hashed variation of that).
Back to Lee for review in case he has the time, I will pass this by Bálint tomorrow morning.

(trying to categorize this, not sure what is the best match, assuming Page builder)

Appreciate that! 😊

But it should be , since this is a problem only for the js ComponentSource plugin ("code components").

penyaskito → credited effulgentsia → .

Ended up implementing a MockVersion for testing purposes. All feedback addressed.
Crediting effulgentsia for feedback on MR.

This looks really great!

I think long term we should consider what both @larowlan and I suggested (in #9 and #4), having Vite/Rollup output filenames with a hash in them. That would allow us to do releases with backend-only changes where we don't force re-downloading unchanged JavaScript assets.

Oops, didn't mean to do that.

#17++ — but we'll still need what this MR does for the xb-ui asset library's definition itself. Tagging for this 👍

So very close!

Reflecting the slightly expanded scope per @balintbrews and my request 😇

Now we fallback to AssetQueryString also in xb-ui and astro libs.

#17, #19: That might make harder to include the assets as we do right now, and specially would make tests more complicated? Not sure how worth would it be, and it would differ from what core does.

LGTM — and many thanks for the ℹ️ comments on the MR, @penyaskito!

Just added some clarifying comments based on the discussion on the issue + MR and fixed some language nits — 🚢

🥳

Still needs follow-up issue for #4 + #9 + #17, which are all about the same thing.

Thanks, @mayur-sose!