Problem/Motivation
When the module is enabled and you use some external cache, for example Varnish with long TTL setting you may face the situation when cached pages reference files that were deleted, cause module clears public://js/delayer folder on the each cache flush. And the cache flush doesn't necessarily mean that the external cache of the page will be invalidated too.
Steps to reproduce
- Enable and configure the module
- Enable and configure varnish, set TTL to some long-term
- Ensure that page uses script from public://js/delayer/... folder
- Do any change in a script included into the delayed bundle
- Visit the cached version of the page and see the error in console
Proposed resolution
Use the same approach as core's asset.js.collection_optimizer service (see Drupal\Core\Asset\JsCollectionOptimizer::deleteAll)
Remaining tasks
I'm providing a patch here, but I'm not sure if the threshold should be moved to the module settings or we can keep using the setting from system.performance. Kept that part unchanged for now.
Issue fork libraries_delay_load-3215993
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #3
artem_sylchukAttached the MR
Comment #6
vdsh commentedThanks Artem for the detailed explanation & merge request. Doing exactly as in Core in Drupal\Core\Asset\JsCollectionOptimizer::deleteAll, tests are passing, I don't see any reasons to not commit it
I also don't think we need a specific setting for this, as it's reproducing exactly Core's behavior, so let's keep it simple & consistent