Roadmap for deprecation and removal of @import

[querkmachine]

Hi, sorry if this is the wrong repo for this—it seemed the most relevant given this is about admin rather than Sass itself.

When the module system was launched it was stated that (emphasis mine):

The Sass team wants to allow for a large amount of time when @‍use and @‍import can coexist, to help the ecosystem smoothly migrate to the new system. However, doing away with @‍import entirely is the ultimate goal for simplicity, performance, and CSS compatibility. As such, we plan to gradually turn down support for @‍import on the following timeline:

• One year after both Dart Sass and LibSass have launched support for the module system or two years after Dart Sass launches support for the module system, whichever comes sooner (1 October 2021 at latest), we will deprecate @‍import as well as global core library function calls that could be made through modules.
• One year after this deprecation goes into effect (1 October 2022 at latest), we will drop support for @‍import and most global functions entirely. This will involve a major version release for all implementations.

However, with the deprecation of LibSass, circumstances seem to have changed, and Dart Sass has yet to deprecate @‍import because of developer friction (sass/sass#3223).

Is there any roadmap (no matter how vague!) to when this is likely to happen? We'd like to start migrating our existing libraries to Dart Sass and the module system now that LibSass has been deprecated, but it's proving harder to prioritise against other work given there's no timescale to when changes are likely to take place.

Having an update published somewhere more visible (and not just a response to a GitHub issue) would be useful too.

Thanks!

[stof]

The https://github.com/sass/sass repo is a better place for that, as it is about the Sass language itself, not about the website

[querkmachine]

I was working on the basis that this is an issue more about documentation than it is the language itself, even if it relates to the status of a language feature. It can be moved if that's the more appropriate place, though!

[stof]

Deprecating a feature is not about documentation. It is about changing the language

[querkmachine]

I still disagree, given I'm asking them to provide updated documentation about a deprecation that has already been announced will happen; but I'll open a second issue in the other repo pointing to this one.