Deprecate and remove @import #3513
Comments
|
Please do NOT deprecate nor remove @import. Users hate unnecessary deprecations for a reason. If something is widely used, that should be more than reason enough to support it. The rationale for dropping @import makes no sense to me; the "advantages" are useless in my & many others' use cases, while causing pain and extra round trips. The alternatives are not replacements for @import, they're different commands for different use cases. Please continue to support both. It's fine to suggest in the documentation for @import "in most cases you should use @use and @forwards instead because ABC" but that's different than removal. I had no idea this was going to removed until I looked it up for unrelated reasons - most users' first inkling that you're dropping support for a widely-depended-on functionality is when their upgrades cause failures, which may lead them to drop the "upgrade". One of the most common uses of sass is in support of GitHub pages, which uses Jekyll and Jekyll templates which in turn use scss. They recommend using @import, resulting in probably millions of sites depending on @import: https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/adding-a-theme-to-your-github-pages-site-using-jekyll This will lead to a gradual and unnecessary fork between what works. Again, please do NOT deprecate nor remove this. Thanks. |
|
This isn't a decision we came to lightly. We recognize that deprecating and removing a feature that was once so widespread is a difficult process, which is why we're doing everything we can to ease the journey. It's been almost four years since we launched the module system; it will be years more before we finally make Cases like Jekyll are a good example of why we need to begin to issue deprecation warnings. There's no reason Jekyll can't use the module system, but they may not even know that they should. Deprecations are a crucial part of the communication process when an old and bad feature needs to be turned down. |
|
I believe the case I made in #3628 is a good reason to not deprecate @import. While I agree that most cases do not require global imports, and would suffer from them, there are still cases where global imports are required! Removing this feature would hurt the language, and I agree with @david-a-wheeler that the consequence would be that there will be a fork of this project that still has this feature. Maybe instead of deprecating the features, there should be a warning of sorts? |
|
A case where global variables are lightly useful is not very compelling here, because it has to be balanced against the systemic problems they cause in the language as a whole. The example in #3628 doesn't even get much more verbose with |
|
After careful consideration, I think you are right. It would be more annoying to develop certain aspects, such as conditioned imports for theme pallets but the simple workaround is having a file that handles which pallet is loaded. Point is, you are right - the benefits of removing Without global imports, each file can work on its own, which would remove a lot of confusion, painful debug and compiler issues. |
|
I've used SCSS for ages but never paid attention to its development. Hell, I just found out that Node SASS was depreciated. So I'm playing catchup and this depreciation has me befuddled. The problem that kicked this off was that some people were having naming conflicts, right? And the solution was to add "use" so that they could have namespaces, right? Then that's all handled. What problem does removing "import" solve? What problems might it cause?
ShadiestGoat said, "...most cases do not require global imports, and would suffer from them". Do you have an example? I can't even picture writing SCSS w/o global variables. Also, in regard to "it's very standard in almost all programming languages", is the goal for this to be a programming language? Today is my 1st time looking at Dart Sass. I have no idea what y'all got cooking. Got a roadmap? |
|
I'm not on the development team, however, I assume a major problem global imports cause is that files cant be compiled separately if they require global imports. Most likely, this causes many systemic issues, technical debt & baggage. With regards to my comment on projects that 'require' but not really require global imports, I was mainly talking about theming. As an example, lets use a setup where we are building a theme (like a gtk theme). In this example, it is quite common to use global variables. Lets say the setup is that this theme can have many different color pallets - say like 16, 20 or hell, even 50, and the theme can have many different options. It then makes sense for a root file to import the correct color pallet partial as a global import, and then all the other files have access to the correct pallet, and sets the options. However, the problem with this approach is that its harder to maintain. Now, in order to find what a variable is you cannot look at just the scope of the file, but you also have to search 'up the tree' - which is tedious, and most likely a difficult task for an lsp. In contrast, if you have a separate file that handles the pallet import (see example below), you can track the origins of variables easier, and the lsp can work just fine. This also means that you can compile this file without a dependence of other files which is not just a really nifty feature, but it also allows for faster updates - only recompile that which is necessary. Example data structure: Where I can't answer any other questions - thats for the dev team. I can note that I think that when @nex3 said that it's standard in almost all programming languages, they meant that its a standard practice in the field rather than an intent to make it a programming language. However, it does bare similarities with some of the @ rules - if statements, functions, debug (ie. print), etc. I doubt the intention is to make this language me able to run DOOM though, haha. |
|
I think I've explained why imports and global scope are harmful as well as I'm going to be able to, both here and in the module system proposal, so I'm not going to belabor the point. However, let me clear up a few misconceptions:
One of the major values of the module system is that it does allow us to cache shared stylesheets in memory. I recommend reading through the proposal and documentation for full details.
Sass has been a Turing-complete programming language ever since we added lists to the language in 2010. It's not a general purpose programming language, but it is still a language, and in particular the concerns about "how do you share members across different files" are essentially the same as in any other language. |
|
Thanks for the replies, especially that link. The @use caching is awesome. And I didn't realize that Sass was so powerful. That said, this still looks like a coding standards issue that doesn't justify all this disruption. I recommend looking at the WordPress Gutenberg situation. The devs spoke to other devs and came up with a dev solution that the devs loved. The silent majority of users weren't on board. The dev team expected the transition phase to last 3 years. It's been extended to at least 6. It's impossible for devs to take the temperature of people who don't join the conversation. And it doesn't matter if it's better, faster, and helps you lose weight. People want what they want. The case that something as powerful as SASS should have namespaces is solid. |
That's just it. If you don't participate in the open discussion about these features when their design is considered, you make it impossible to take your perspective into account. Coming in years later and saying "I wish you'd considered what I think about this" isn't very compelling at that point. That said, even if there had been some objection at the time to removing the global namespace, it's likely we'd have done it anyway unless that feedback was truly overwhelming. Moving away from
These are very different languages we're talking about. There are hundreds of developers working on C and C++ compilers who can help shoulder the burden of supporting legacy features; Sass has four, whose time is split between it and other work. C was 24 years old when the first major programming language with scoped loads was introduced; Sass was 13 when it launched its module system. C and C++ can essentially avoid any breaking changes; Sass users must accept some breakages as the cost of keeping up with new CSS features. |
|
I agree that @import url("fineprint.css") print;
@import url("bluish.css") print, screen;
@import "common.css" screen;
@import url("landscape.css") screen and (orientation: landscape);
@import url("gridy.css") supports(display: grid) screen and (max-width: 400px);
@import url("flexy.css") supports(not (display: grid) and (display: flex)) screen
and (max-width: 400px);
@import "theme.css" layer(utilities);I have sensed this because I wanted to import Bootstrap CSS into a separate layer, since I found better ways for cascading than @import "https://cdnjs.cloudflare.com/ajax/libs/bootstrap/5.0.2/css/bootstrap.min.css"
layer(bootstrap);However, importing this into an unnamed layer works as expected. |
|
@Keyacom The second-to-last @import url("flexy.css") supports(not ((display: grid) and (display: flex))) screen
and (max-width: 400px);Otherwise, all of your examples are parsed by Sass as plain CSS imports. |
|
Whoops, sorry. Must have not checked the Sass version, which is 1.32.0 on CodePen, where I was testing this. |
|
I am definitely against the removal of @import rule. Maybe you can remove @import keyword for css comatibility, but definitely keep global import as a thing, maybe something like @use "xxxx" as yyyy !global; We're using partials for every block in our design, and a lot of them are less than 10 lines of css and add several lines of @use's to EVERY partial is a HUGE disadvantage - it is polluting code, you have to think about it every time you create a partial, etc. People will lean towards creating big partials with a lot of blocks in it just not to mess with imports every time. Maybe you're thinking too much about framework developers, big libraries like bootstrap etc, but forgetting that 90% of sass code is written in simple projects where global imports are reducing a lot of unnecessary work. @use is great, but keep global imports, please. And you're right, every modern programming language has some sort of @use for import, but keep in mind that every modern programming language has smart IDE which makes shure you dont have to think about those imports ever. |
You can mitigate this by grouping commonly-shared files into
And IDE developers are encouraged to implement this for Sass as well 🙂. In fact, one of the critical benefits of a world without |
|
I can see a real problem here. The reason SCSS has won the preprocessor war is that it was very convenient for big framework developers. LESS was more user-friendly (IMO), but when frameworks like Bootstrap switched from Less to SCSS, it was basically game over - all the end-users followed. However, framework developers have very different requirements than end-users. They need modularity, namespaces, etc., while end-users need simplicity.
Yes, but you still need to add @use in every partial, even if it has 3 lines of CSS.
Eggs should come first. By the way, I've never had a problem with current IDE support; it can detect all the variables and components pretty well. And you will still need to scan all code for mixins and variables if you want to support auto-@use generation by IDE. One more example (base is a folder with _index.scss combining dozens of partials): @layer base {
@use "base";
}If @import will be removed the only way i see is to convert every partial to mixin instead of CSS output, more boilerplate, more room for error. |
|
To be clear: Here are the critical points:
|
|
I can clearly understand all the benefits of @use, and I also understand that my messages probably won't change anything, but here are my critical points: You are planning to remove a part of the language that has been present since the beginning, and this change will significantly impact many "sleeping" users who utilize SASS as a straightforward CSS replacement. While JavaScript has a module system, no one is considering removing the global scope. "Small" projects may appear simple in terms of mixins and SASS code, but they often contain a substantial amount of CSS code. For instance, our last project comprised over 200 BEM components, each in its own file, with only 10-15 SASS mixins for media queries and typography. We do not require any static analysis or advanced features, just some basic utilities to expedite development. This scenario mirrors the majority of end-user websites: unless you're constructing a CSS framework, you typically only need a limited number of mixins placed in your "lib" folder. Imagine car company like Ford prioritizing their race team and banning automatic gearbox from all of their cars because manual gives way more control - thats how I see it from my perspective. |
|
Keeping |
|
You're just proving my point – you want to make people's lives harder so that robots' lives would be easier. Having to manually @use imports in EVERY partial is a huge disadvantage for everyday work, especially in the absence of good IDE support (and please don't tell me IDE support will follow – I seriously doubt it given the effort needed to implement such functionality). Having to import system libraries is dubious too – every language has a list of functions that are auto-imported and available; even ultra-verbose Java has java.lang. But I have to type @use "sass:color" as color at the top of every partial when I want to change a color a little bit. I know you have a list of global functions, but you're gonna deprecate and remove them as well. As I mentioned earlier splitting your styles into lots of partials is a very common approach that simplifies maintenance later on, and at least for now I have an option to @use "sass:color" once and create my own delegate functions I can import globally. I can totally understand that @import, in its current form, is a suboptimal solution, but there needs to be a way for some sort of @use propagation, or you will make a lot of people's lives much harder. |
There is: |
|
In Dart Sass 2.0.0, which will be released this year, |
|
@jathak reminded me that the plan is actually to deprecate |
|
I just started using Sass in a project for the first time and I tend to agree with @grobitto. This goes even further than the issue with partials. Suppose I have a library with mixins that take some arguments: Now I have several components which need to include this mixin in their CSS. The component modules themselves can be configured in such a way that it changes some of the args that are passed to the mixin. However, there is a standard configuration for each component and this standard configuaration is also shared between multiple components: Because I have to repeat the same default configuration in several component files, I put the lines from above code snippet where it applies default values for Now I found out that Removing the So what's the supposed way to do this? Without |
|
What you've written works as-is. If I assume .example-style {
args: some-custom-value, some-value, some-value;
}
.example-style {
args: some-other-custom-value, some-value, some-value;
}Generally speaking, we recommend avoiding top-level styles in partial files like your components, whether you're using // component1.scss
@use 'library';
@mixin style(
$mixin-arg1: some-value,
$mixin-arg2: some-value,
$mixin-arg3: some-value,
) {
.example-style {
@include library.my-mixin($mixin-arg1, $mixin-arg2, $mixin-arg3);
}
}This way, you can layer on different argument defaults or re-use component styles arbitrarily without running into any restrictions on loading a module multiple times with. |
|
i try to understand how i move from @import to @use or @forward, but given the documentation for @use and @forward did not explain verymuch to help me with the problem i hope you can help me out a little bit and explain how we are supposed to setup things in the future. our project basically consist of 3 folder
we use two main scss file that @import other files for the theme directory or the shared directory
i was able to @use files from the shared/sccss folder within the styles.scss without a problem. but now i am struggling to understand how the shared "header.scss" file is supposed to read the variables from theme_1 or theme_2 without the global imports While most of the scss is identical for both themes we do have complete differents colors / fonts for each theme, hence most of the scss is in the shard folder. Also please understand that everything is split up in logical blocks based on the context of the project (headedr, footer, components, pages and so on. ) so something like colors variables need to be read in lots of different files from withing the shared folder. at the moment we are using dart-sass and php storms file watcher to run the compile for us. |
Can you provide some more details about what information you were looking for from the documentation that it didn't provide? Please note that we try to keep this issue tracker focused on bugs and feature requests that need the core team's attention in particular, while requests for support are usually better handled by the community at large on sites like StackOverflow.
If you're trying to have your shared partials generate different styles based on which theme they're used from, you should make that explicit by making them mixins that take parameters, rather than emitting top-level styles that just expect certain variables to ambiently exist: // shared/scss/partials/header.scss
@mixin header($header-background-color) {
.header {
background-color: $header-background-color;
}
} |
i think i was looking for one or two more practical examples / usecases....
Understandable...I was just looking up what was going on about the @import deprecation, in search for practical pointers on how to act on that. |
|
Well, just like many other devs that are catching up to this deprecation of @import... it's a bummer, even after reading the documentation I still burned a tone of time trying to make things work and reading as reference the code in latest Vuetify and Bootstrap. Knowing that this ship has sailed and it wont change, but maybe something that would have enabled the users (the devs) more control over how they needed the feature to behave, could have been to use a similar syntax as JavaScript modules: @import "scss-file" as $[namespace]; Or maybe rename the method to avoid conflicts with the css standard, could have been @insert "scss-file"; Regards 👋 |
|
I totally agree with @carlosjln, backend and frontend have different challenges and rules and something that works in one scenario doesn't necessarily work in other. One of the greatest aspects of SCSS was flexibility and customization, some companies (like us) have a well defined style that is carried across projects with intention. You come to me because you want my style. And that is something that was built over a decade and that has a complex ecosystem of variables, mixins and more that do magic in SCSS. The new way of working will fight against that in many ways, of course there is a way of working the new way around, but it's less flexible and less efficient. So to speak if flexibility goes away as it will, there are better alternative to SCSS. So basically SCSS will kill SCSS just like newspaper killed themself trying to copy social media. Is it philosophy? Yes. Will this help? Probably not. |
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I'm going to lock this thread because most of the new comments at this point are just complaints. If anyone has a specific structure they're struggling to migrate, we're happy to help. I also have a couple general suggestions:
|
We've recently reached the threshold where >80% of total Sass downloads on npm are of Dart Sass, which means it's time to start thinking about deprecating and eventually removing the
@importrule. Because deprecations are highly annoying for users and@importis widely-used, we want to do this as gently as possible and continue to give users plenty of time to migrate. To that end, here's the current plan:@importdeprecation (Add a --future-deprecations flag dart-sass#1363)@import@importby default@importThere's also the question of a timeline for these. I think the first three steps should be handled as quickly as possible. I'd like to leave at least six months between the blog post announcing
--future-deprecationsand the actual default deprecation, so that users have some warning for the deprecation coming down the pipe. Once@importis officially deprecated (judging by the time it's taken to get to where we are now) I think we'll want to wait at least two years before fully dropping support, with the option to extend if necessary.This means the removal of
@importwill probably end up as Dart Sass 3.0.0, with an intermediate breaking release in between. We could potentially target the@importdeprecation to Dart Sass 2.0.0, but I'm worried this would motivate users to avoid upgrading and thus make an eventual upgrade even more frictive due to smaller breaking changes.The text was updated successfully, but these errors were encountered: