diff --git a/source/blog/024-the-module-system-is-launched.html.md b/source/blog/024-the-module-system-is-launched.html.md index 11461bf06..ce7272324 100644 --- a/source/blog/024-the-module-system-is-launched.html.md +++ b/source/blog/024-the-module-system-is-launched.html.md @@ -337,15 +337,22 @@ 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 +- ~~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. + be made through modules.~~ -- One year after this deprecation goes into effect (**1 October 2022** at +- ~~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. + entirely. This will involve a major version release for all implementations.~~ -This means that there will be at least two full years when `@import` and `@use` -are both usable at once, and likely closer to three years in practice. +~~This means that there will be at least two full years when `@import` and `@use` +are both usable at once, and likely closer to three years in practice.~~ + +**July 2022**: In light of the fact that LibSass was deprecated before ever +adding support for the new module system, the timeline for deprecating and +removing `@import` has been pushed back. We now intend to wait until 80% of +users are using Dart Sass (measured by npm downloads) before deprecating +`@import`, and wait at least a year after that and likely more before removing +it entirely.