I have been trying to disable caching during development so I followed drupals guide step by step: https://www.drupal.org/node/2598914

After doing this I would assume that the caching is completely disabled but when I am loading a js/css file for a specific module in mymodule/mymodule.libraries.yml I still have to clear all caches for me to see any updates.

How do you disable caching for attached libraries in custom modules?


  path: '/test-me'
    _title: 'Testing module css cache'
    _controller: 'Drupal\test_module\Controller\TestController::test'
    _permission: 'TRUE'


  version: VERSION
      test.css: {}



namespace Drupal\test_module\Controller;

use Drupal\Core\Controller\ControllerBase;
use Drupal\Core\Render\Markup;

class TestController extends ControllerBase
    public function test()
        return [
            "#markup" => Markup::create("<div class='test-class'>Hello World</div>"),
            '#attached' => [
                'library' => ['test_module/test']


.test-class {
    padding: 40px;
    background-color: blue;

If I change the background-color to red for example, and refresh the page (F5, Ctrl+F5, Ctrl+Shift+R, Right click refresh -> Clear cache and Hard Rest), it will not change to red until I clear all caches.

What piece am I missing to make this work? Or is it just not possible?

Note: It doesn't matter if I clear my browser cache at all (I currently have it disabled with devtools open)

3 Answers 3


You are on the wrong track. Caching of static assets (and CSS files are static assets when you disable CSS/JS aggregation) has nothing to do with Drupal's cache. Disable the caching of *.js and *.css files on your web server instead (e.g in .htaccess if you are using Apache).

  • Yes, although Drupal tries to overcome this restriction by adding a cache buster query string, which is changed on a cache clear, so it appears that Drupal clears CSS, but in reality it doesn't.
    – 4uk4
    Commented Nov 13, 2018 at 8:06
  • The cache buster string only really works well with aggregation enabled and drush cr. With aggregation disabled, the query string for custom libraries is just the version number from the library.info, which is not really useful when iterating quickly over CSS on local dev
    – Hudri
    Commented Nov 13, 2018 at 8:12
  • Without aggregation this works for CSS as well, only for JS you need to adjust the version number. What I meant, the OP expects that Drupal can clear CSS automatically, because Drupal can do it manually by drush cr. But Drupal doesn't have control over static CSS files, as you pointed out in the answer. Drupal simply invalidates the cache-buster each time the cache is cleared, without knowing whether CSS files were modified.
    – 4uk4
    Commented Nov 13, 2018 at 13:18
  • Thank you, I will look into disabling the caching in nginx and see if that does the trick.
    – sceithamer
    Commented Nov 13, 2018 at 15:33
  • Man I was so convinced drupal was caching it. Thank you so much for pointing me in the right direction. Updating nginx to not cache static files (css/js) saved the day.
    – sceithamer
    Commented Nov 13, 2018 at 18:37

You should simply remove the version: VERSION line, because this declares your library to be the same version as your Drupal core version, which does not change as often. By deleting this line, Drupal will add a default query string that changes after every cache rebuild/deployment, so it will naturally cache-bust.

See https://chromatichq.com/insights/drupal-libraries-version/ for more information on the VERSION value in libraries and why it shouldn't be used by anyone outside of core.


You can use the js_cache_buster module and add the enable_buster: true value to the js you want in your library.yml file. This will increment the ?v= value each time the cache is cleared.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.