I have a little confusion with how to use @use and @forward. If my understanding is correct, @forward will allow me to load variables, mixins, and functions while also allowing me to store all the sass files into one like this:
// _index.scss
@forward "fonts";
@forward "mixin";
@forward "var";Which means then, that I have access to every file item within it. if I am currently in _header.scss and wanted to have access to the _mixin.scss file, I would have to write @use to have access to the file.
My question then is: Do I have to write a @use "index.scss" in every file that I need it? Such as:
in _footer, @use "index.scss"
in _header, @use "index.scss"
Or is there a short cut to writing it only once and have global access given to all files?
Another question is: does anyone have an github file example of how to set up the scss files using @use and @forward?
How do I access a variable that was forwarded?
I tried the below but provided no results. And apologies for asking too many questions
I tried the below but provided no results. And apologies for asking too many questions
//_index.scss
@forward "fonts";
@forward "mixin";
@forward "variable" as var-*;@use "index"
header {
background: index.var-$headingColor; <-------- here is the error
}
With that being said, what are your thoughts regarding, Tailwind/PostCSS? These two tools play well with each other, and I hope Sass can bring about new features to help stay relevant and competitive in this market.
99% of people using PostCSS are only using it Auto-prefixer, and may not even realize that PostCSS was how Auto-prefixer worked. The other 1% are mostly people recreating Sass features in a less elegant, less tested, but more customized way. Excluding people making their own CSS tools and using PostCSS as a dependency for parsing, etc.
Tailwind seems to be very popular to a small minority of devs, hated by another small minority, and just ignored by everyone else. It seems to really attract people that don't know much about CSS and don't understand the downsides of using Atomic CSS exclusively. Atomic CSS is good in small doses, but Tailwind takes it to the extreme and applies it religiously. A far better approach would be to just atomize your styles after the fact. I'm working on a CSS Atomizer library for that reason (Red Perfume)
There have been attempts in the past to make plugins for Sass, but the problem is they are language specific. Compass was popular in the early days but required Ruby. Eyeglass attempted to do similar stuff, but for Node and never really caught on. Not sure if there are any Dart attempts
Great insight Jared, yes I agree with Tailwind's extremeness. I am currently in the process of finishing the documentation for UniformCSS which is suppose to be a TailwindCSS alternative done in Sass. The CSS Atomizer seems like a really awesome project I'm in the process of checking it out now.
I think going forward Dart attempts would be quite awesome since it seems like the new Dart version of Sass is now here to stay. I personally don't know much about the dart language, but this gives me a lot of reason to learn.
I think going forward Dart attempts would be quite awesome since it seems like the new Dart version of Sass is now here to stay. I personally don't know much about the dart language, but this gives me a lot of reason to learn.
One thing that would make a huge difference for tooling would be direct access to an officially maintained Sass AST. To quote Natalie: "eventually we want to write a translator from the Dart Sass AST to the PostCSS AST which would also work for the indented syntax, but that's pretty low priority"
That would unlock lots of tooling and plugins if available. like better linting, code quality enforcement, code mods, reporting/analysis tools, etc.
We could make an external AST parser, but those always get out of date, are missing features, and can be buggy. It's always better if the AST can be produced directly from the source, so it's always up to date and accurate
Hello -- I just wanted to share I made a very small VS Code extension to support inline Sass syntax highlighting (like using sass
... template strings in JS). It turns out it was really only a few lines of code so I wanted to share the repo here just in case it’s relevant to anyone’s interest https://github.com/zaydek/vscode-sass-template-strings
Here’s how it works and why -- I wanted a way to colocate Sass code that gets compiled ahead of time
ideally any syntax highlighting you make covers both syntaxes
not sorry that that guy isn't using Sass!
Hi all. I just updated Dart Sass to 1.33.0 and I got a million warnings in my console. Most of them from
bootstrap-sass. They, being a library, probably want to support at least a few versions of Dart Sass (i.e. users using different versions). However, math.div is not available in previous releases. So what are libraries like that supposed to do - that is, can they have code that both works and emits no warnings for the last few Dart Sass versions?
fallback to v1.32.* or remove
bootstrap-sass dependency. I noticed that bootstrap-sass is a non-active project and lack maintain. It means not easy to push glebm to support math.div. If you need use latest version dart-sass and bootstrap-sass, maybe you can try patch-package to solve npm dependency.
And I try to create a pull request for
bootstrap-sass, but no promises .
Thanks for the answer. The problem is that even if you create a PR for
bootstrap-sass, that will work only on Dart Sass 1.33+. That is, someone who is still using Dart Sass 1.32 would have to stay on the old version of bootstrap-sass. That means that bootstrap-sass will have to release a major version because they are breaking backwards compatibility. But they can't do that because bootstrap-sass version 3 is for Bootstrap version 3...
Perhaps an option could be added to Dart Sass that suppresses warnings in certain files/packages. I don't see another good way of resolving this problem.
I'm not sure what the homebrew command to upgrade is, though
It was
brew update