I have worked in Drupal projects where SASS was used to generate CSS files in a theme (with gulp or compass).

I have also worked in Drupal projects where a lot of the CSS (without SASS) was living in custom modules, to style Drupal components (views plugins, ds layouts, field formatters, etc).

I am now wondering what would be the best way to combine both worlds:

  • Have SASS sources distributed in distinct (custom module) directories, and some in the theme.
  • Allow to include sources from other modules. Of course dependencies must be declared accordingly.
  • Allow contrib modules, or "corporate" modules that are meant to be reused, to ship with SASS sources.
  • Watch the entire tree with gulp or compass, without watching the toplevel dir.
  • Generate the CSS files in a common directory, or in distinct directories, I don't care that much.
  • Have some way to control which generated CSS file is included on a page.

The main limitation of SASS seems to be that it is limited to one directory, where you keep all the source files and that you watch with gulp or compass, and one output directory for the finished CSS files(s). At least this seems to be how it is commonly used. This is not ideal if I want to distribute the CSS across module directories.

For now the question is quite open-ended, perhaps someone already did this and can describe a workflow / architecture.


The project I am asking this for is currently on D7, but will move to D8 soon. I would be interested in both, but will mark it as "8", and hope I can then apply a similar technique to D7.

Theme CSS vs module CSS?

Some developers have quite strong opinions about the location of CSS files, accepting only the theme as a valid place for anything front-end related. You are free to share such opinions, but please don't make this the only part of the answer!

Is this a Drupal question?

Perhaps the individual technical obstacles are not specific to Drupal. But my use case is, and I am hoping that someone else had a similar scenario.

  • 1
    I acknowledge that you took quite some effort to write up this question. Unfortunately this is a completely opinion-based thing. Means you need to come up with a solution that you think fits best. At least I can tell you about compony.io which is an approach to make this whole theming thing a little bit more reusable. But still this happens only in the theme. Where it actually belongs to IMHO.
    – leymannx
    Commented Nov 12, 2019 at 20:04
  • Providing low-speficity CSS out-of-the-box for modules is important too though. /opinion
    – mradcliffe
    Commented Nov 13, 2019 at 12:21
  • 1
    I have some arguments here, but I am afraid this would lead us down a long tangential path. In short, I like to create custom formatters, views plugins, ds layouts etc (and most importantly renderkit components) that provide a full visual experience, so the module would be the most natural place for the accompanying CSS. Themes cannot define formatters or plugins, and even if they did, there would be a problem if you try to run this in a different theme. Also, a theme can get crowded very fast.
    – donquixote
    Commented Nov 13, 2019 at 13:33
  • In fact I am contemplating a possibility to define renderkit components or variations in a theme, which would fall back to a module component if the theme is changed.
    – donquixote
    Commented Nov 13, 2019 at 13:34
  • 1
    Related: #474684 Allow themes to declare dependencies on modules. Means you keep theming in the theme and let a theme have dependencies on modules which provide custom formatters etc.
    – leymannx
    Commented Nov 13, 2019 at 14:31

1 Answer 1


By concept a contrib module will hardly ever be able to use SASS, because SASS simply is not part of Drupals distribution. But that doesn't mean your local environment cannot use shared SASS resources for custom themes and custom modules.

E.g. in all our projects, the project-specific theme is a sub-theme of a shared, immutable base theme providing defaults and mixins. We are compiling with a bash script using standalone SASS with the --load-path argument:

sass ./web/themes/custom/PROJECT/scss/THEME.scss ./web/themes/custom/PROJECT/css/THEME.css --load-path ./web/themes/custom/SHARED_BASETHEME/scss

in ./web/themes/custom/PROJECT/scss/THEME.scss

@import "default_settings"; /* lives in SHARED_BASETHEME, bunch of $variables with !default */
@import "settings"; /* lives in PROJECT, partially overrides default_settings */

I'm quite certain there is something similar for the Node-Version of SASS (or in Gulp). With a black belt in in Bash-Fu (or in your case: Gulp-Fu) this can be extented to any custom module and any custom theme and vice versa.

Example with multiple themes:
We had one project using Domain access module and one sub-theme per sub-domain and we handled bulk theme compiling with a bash script:

for D in ./web/themes/custom/*/;
  if [ -d "${D}" ] && [ "${D}" != "./web/themes/custom/SHARED_BASETHEME/" ] && [ "${D}" != "./web/themes/custom/EXCLUDE_ME_2/" ]; then
    echo "Creating sub-theme ${D}"
    sass ${D}scss/THEME.scss ${D}css/THEME.css --style expanded --load-path ./web/themes/custom/SHARED_BASETHEME/scss
  • If I understand correctly you would have to run this again for each module containing SASS? Or you would have one scss file where everything is assembled together - but then you'd have to modify this whenever you enable or disable a module.
    – donquixote
    Commented Nov 13, 2019 at 15:10
  • That is where the Bash-Fu comes in, see updated answer Example with multiple themes. I'm not using it, but I'm sure this is possible with Gulp too.
    – Hudri
    Commented Nov 13, 2019 at 15:19
  • You could wildcard the path in Gulp too and consume Sass in various directories. But yes you'd need to be aware of enabled modules. Perhaps commands combined with Robo may be the ticket?
    – Kevin
    Commented Nov 13, 2019 at 16:04
  • Regarding enabled modules: I guess with careful planning this could be outsourced (or better: insourced) to D8's library system. Keep the (S)CSS files small and modular, make a dumb built process that compiles them all and bundle/enable them with Drupal's library system.
    – Hudri
    Commented Nov 13, 2019 at 16:46

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.