Removing @import should be stopped

[dtvn]

I agree that we need local vars. But at the same time, global var does bring benefit for certain reason. Moreover, @use does not have some good features like @import, which it supposed to have. For instance, nesting is a very important one that @use should have. But it doesn't.

On the global, we need it to set global configuration (a fixed one). Please refer #2750

For now, I decide to use both for whatever convenient for me. But I sure hope that we didn't remove @import and add nesting to @use. Or I will have a tons of extra lines in my code.

[mirisuzanne]

Nesting is still supported with the load-css() mixin - even improved because that mixin supports custom configuration and dynamic importing:

@use 'sass:meta';

@each $theme, $file in $themes {
  [data-theme="#{$theme}" {
    @include meta.load-css("themes/#{$file}",
      $with: ("base-color": $brand));
    }
  }
}

[dtvn]

Now, I'm totally lost. I don't understand where the 'even improved' is.

Why it cannot be like this:

.xyz {
  @use 'xxx' with ( $url: 'to://no.where' );
}

Ain't it much simple?

[jathak]

The main difference between @use and load-css is that @use allows access to a file's variables, functions, and mixins, while load-css only includes a file's generated CSS. One of the goals of the module system is to make it easy to find where a given variable, function, or mixin comes from. To ensure that, we require that @use is at the top-level of a file, before most other rules, and that it refers to a static URL.

Given most nested @imports only cared about the CSS that was imported (and not the variables, functions, or mixins), we still support this behavior via load-css. As a bonus, the URL for load-css doesn't have to be a static string like @import.

You may find it helpful to refer to the "Goals" section of the module system spec to understand the reasoning behind these changes.

[dtvn]

Ok, it seems an appealing solution (load-css). But it's still bugging me at 2 points:

1. The syntax seems getting more and more complex. Does doing this will lose the primary purpose of make CSS be more simple?
2. Even load-css has better feature, that doesn't mean we will always need it. So far, my @import is so simple. It only does one thing, passing global variables. Because of that, I don't think I need such an heavy weapon like load-css.

So I'm thinking about passing external data to scss compiler. Do we have any way to do so? I'm using gulp-dart-sass btw.

[kerryj89]

@dvtn

I agree that it feels heavier compared to the old way. Just my thoughts on the direction of SASS...

It's one of those things where you either make things dead simple and abstract the complexities that'll later bite you with debugging hell in complex apps (LESS) or you make things a little more stricter upfront to prevent that from happening but have more to grasp about the inner workings (SASS as of late).

To me having used both LESS and SASS, I feel LESS is like jQuery with things just working and easily understood where SCSS is getting more and more complex and programmatically structured like some of the JS frameworks. LESS may be the better solution for people with simple setups but SASS offers more power for others that have more advanced setups.

For simple projects I'd recommend LESS to hit the ground running and for more advanced ones I'd go with SASS. Obviously go with the language of whatever framework you're using. Bootstrap 4 uses SASS now and so I've been using it.