Include base styles in subtheme

[chrisdarke42]

Either the styles.scss needs to @import the styles from the contrib, or we can import it in in laravel mix using an approach similar to:

.setPublicPath('public') .setResourceRoot('../../') .js('resources/js/app/app.js', 'public/js/app') .sass('resources/sass/app/base.scss', 'public/css/app') .sass('resources/sass/app/layout.scss', 'public/css/app') .sass('resources/sass/app/components.scss', 'public/css/app') .sourceMaps(true, 'source-map')

[chrisdarke42]

to be clear the laravel mix example was copied from https://guillaumeduveau.com/en/drupal/theme/laravel-mix

[whereismyjetpack]

@import seems to work, however, sass gives us this warning

⚠️ Heads up!

The Sass team discourages the continued use of the @import rule. Sass will [gradually phase it out](https://github.com/sass/sass/blob/main/accepted/module-system.md#timeline) over the next few years, and eventually remove it from the language entirely. Prefer the [@use rule](https://sass-lang.com/documentation/at-rules/use) instead. (Note that only Dart Sass currently supports @use. Users of other implementations must use the @import rule instead.)

What’s Wrong With @import?

The @import rule has a number of serious issues:

    @import makes all variables, mixins, and functions globally accessible. This makes it very difficult for people (or tools) to tell where anything is defined.

    Because everything’s global, libraries must add a prefix to all their members to avoid naming collisions.

    [@extend rules](https://sass-lang.com/documentation/at-rules/extend) are also global, which makes it difficult to predict which style rules will be extended.

    Each stylesheet is executed and its CSS emitted every time it’s @imported, which increases compilation time and produces bloated output.

    There was no way to define private members or placeholder selectors that were inaccessible to downstream stylesheets.

The new module system and the @use rule address all these problems.

How Do I Migrate?

We’ve written a [migration tool](https://sass-lang.com/documentation/cli/migrator) that automatically converts most @import-based code to @use-based code in a flash. Just point it at your entrypoints and let it run!

@use does not import variables.

@use with @forward will create an import loop and get sick
sass/sass#2774

I'm not sure the best path forward,

https://drupal.stackexchange.com/questions/238465/use-sass-variable-and-mixins-from-base-theme-in-sub-theme
https://sass-lang.com/documentation/at-rules/import/

[cjwetherington]

@whereismyjetpack Re: @use with variables: this does seem to work okay if one specifies the base theme namespace when referencing the base variables: https://sass-lang.com/documentation/at-rules/use/#loading-members

Locally tested with ROAM (on preview/basetheme branch):

1. Added @use "../../../contrib/psulib_base/scss/style"; as top line in ROAM's style.scss file
2. Changed ROAM's header color to background-color: style.$invent-orange; in its _header.scss file (variable is defined in the base theme's SCSS)
3. Ran ddev theme-build and ddev drush cr
4. Header turned orange

EDIT: Just realized this goes sideways though as soon as one has multiple @use statements. Will keep picking at it.

[cjwetherington]

The slickest thing I could get working with ROAM without using @import is as follows:

/scss
|-- components/
|---- _footer.scss     (@use base theme style.scss if needed)
|---- _header.scss     (@use base theme style.scss if needed)
|---- _index.scss      (built-in file - @forward each .scss in dir)
|---- _node.scss       (@use base theme style.scss if needed)
|---- _views.scss      (@use base theme style.scss if needed)
|-- style.scss         (@use components directory)

Not the most convenient thing to have to call up the base style in each component but that seems to be the intentional design principle.