-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modernise sass build process #6
Comments
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. |
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 - @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 @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 @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'; |
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.
The text was updated successfully, but these errors were encountered: