Versioning css and scripts

keevitaja - 1 month ago


Is there an official way versioning stylesheets and scripts? Like with asset_style() add version key or something

huglester - 1 month ago

For now I did the old Elixir way. I just compile css/js and output them to public. and in the metadata I echo them like elixir('js/app.js');

I think you know how it works!

ryanthompson - 1 month ago

Nothing built in right now no but that's not a bad idea. How would this work do you think?

keevitaja - 1 month ago

This versioning is for browser cache busting.

I do not know, how exactly the asset building is working in PyroCMS, but each time the new asset is built/compiled, either it did not exist, asset cache was purged or assets were updated (this is what causes problems), a new version key is generated and injected into the html tag by asset_style or asset_script

<script src="http://site/app.js?v=3434534">

This version key could be some cheap hash like crc32 or similar. No need to have an incremental integer.

ryanthompson - 1 month ago

I like that. So randomize it during dev and for production it would remain the same unless maybe a bump command or something?

keevitaja - 1 month ago

mhhh, this might actually be better what i was proposing. Like for dev new key is generated for each load but for production you must issue artisan command to pump the version.

thinkgraphical - 1 month ago

+1 for this. Maybe you can get some inspiration from this package:

keevitaja - 1 month ago

@ryanthompson any news about this?

ryanthompson - 1 month ago

@keevitaja @thinkgraphical would something like this work:

{{ asset_style('theme.css#123', [filters]) }}

Then when you change the version number it will force compile?

What's wrong with just asset:clear or even deleting the asset file itself (it will be named theme.css in public/app/REF/theme/*)?

Just trying to get a solid use case cause REALLY.. what is really needed is for more reliable self busting. When files change. Right? Why version?

keevitaja - 1 month ago

It's not about the compiling.

When file name is the same, but the actual file has changed, browsers tend to use the old file they have cached before. So user gets the outdated file.

As i mentioned before, the version has no other purpose besides the browser cache busting. And the idea is, that you do not have to manually bump the version. Check how Laravel's Elixir versioning is working. End goal should be similar.

Thank you!

jerev - 1 month ago

Exactly, it's about cache invalidation for the client.

As Google describes here:

The combination of ETag, Cache-Control, and unique URLs allows you to deliver the best of all worlds: long-lived expiration times, control over where the response can be cached, and on-demand updates.