Update the timeline for removing @import in the module system blog (#651)

This commit is contained in:
Natalie Weizenbaum 2022-07-06 15:43:20 -07:00 committed by GitHub
parent 652e48b022
commit faf93b9cb7
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.