Skip to content
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

Open
woodcox opened this issue Oct 5, 2023 · 2 comments
Open

Modernise sass build process #6

woodcox opened this issue Oct 5, 2023 · 2 comments

Comments

@woodcox
Copy link

woodcox commented Oct 5, 2023

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
Copy link
Owner

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
Copy link
Author

woodcox commented Oct 29, 2023

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';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants