Modernise sass build process

[woodcox]

Hi @BinaryMoon. I think you could remove gulp from the build process and instead use sass and lightningcss to do everything gulp is doing. This would reduce your dev dependencies and may be faster to run dev/build.

Also, you could change from using @import to load the scss modules and instead use @use and @forward.

What do you think? I'm happy to send you a pull request if you wish.

[BinaryMoon]

Hi there - thanks a lot for the interest and comments.

Thanks also for the offer of help! However I don't think I need to switch build process at this time.

FWIW the build process with gulp takes about 2 seconds and I do it maybe once or twice a week, so there would not be big benefits from a build duration pov.

I know Gulp and am comfortable with it - and it does what I need. If I switch and theres a problem I won't be able to fix it because I don't know lightningcss. To be fair I've had a look at the docs and it appears manageable but I like to stick with boring tech that I understand.

The comments about import, use and forward are more interesting though and I will think about that. I think there could be places where they may be useful. If you have examples of how they can benefit ElementalCSS I'd be interested to hear more.

[woodcox]

When you importing sass from multiple sources you may have naming conflicts. One aspect of the @use syntax is to enable name-spacing. For example, in open-props-scss there is a file called colors.scss and colors-oklch.scss. Both have multiple sass variables with the same name - $red-0, $red-1, ... To use them both you do:

@use 'open-props-scss' as op;
@use 'open-props-scss/colors-oklch' as hd;

.my-thing {
  color: op.$red-1;
}

.my-other-thing {
  color: hd.$red-1;
}

Secondly when loading sass modules via @use you can override any sass variable (including maps) that are !default. This is extremely useful! For example if you wanted to extend/limit some of your vars such as your $sizes map you could do:

@use 'elementalcss' with (
  $sizes: (
    '0': calc( var( --size-base ) / 2 ),  // altered
    '1': var( --size-base ),
    '2': calc( var( --size-base ) * 2 ),
    '3': calc( var( --size-base ) * 4 ),
    '4': calc( var( --size-base ) * 8 ),
    '5': calc( var( --size-base ) * 16 ),
    '6': calc( var( --size-base ) * 32 ),
    '7': calc( var( --size-base ) * 64 ),
    '8': calc( var( --size-base ) * 128 ),
    '9': calc( var( --size-base ) * 256 ),
  )
);

You can also override defaults with override scss files where you define the sass variables that override the !defaults in a seperate file:

@use 'override-config';
@use 'elementalcss';

This is described under the configuration heading on sass-lang.com. All this assumes your repo is on npm though.

Thirdly its possible to limit what modules you want to use from a given repo if the repo is modularised. For example, using open-props-scss as an exaample again, you can just include the modules you want:

@use 'open-props-scss/shadows';