SASS for module CSS? 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.

Platform

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.
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/*/;
do
  if [ -d "${D}" ] &amp;&amp; [ "${D}" != "./web/themes/custom/SHARED_BASETHEME/" ] &amp;&amp; [ "${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
  fi
done