Mark LibSass as deprecated

[nex3]

After much discussion among the Sass core team, we've come to the conclusion that it's time to officially declare that LibSass and the packages built on top of it, including Node Sass, are deprecated. For several years now, it's been clear that there's simply not enough engineering bandwidth behind LibSass to keep it up-to-date with the latest developments in the Sass language (for example, the most recent new language feature was added in November 2018).

For the past couple years, we've all been hoping that this pattern might turn around. Marcel's excellent work porting code from Dart Sass looked promising, but it hasn't translated into concrete support for the latest Sass features or major compatibility bugs. At the same time, LibSass's slow pace has begun causing substantial concrete problems for Sass users. We regularly see users confused as to why plain-CSS min() and max() don't work and assuming Sass as a whole is at fault, when in fact it's only LibSass that doesn't support that feature. And we've been unable to move forward with the slash-separator proposal because of LibSass's lack of support.

All of this means that it's time to start directing users away from LibSass, standardizing on Dart Sass as the primary (and for now the only) recommended language implementation.

What does "deprecated" mean?

The term "deprecated" carries a lot of weight in the programming community, and provides a strong signal that users should start planning to move away from a piece of software. That said, it's not rigorously defined, which leaves us a lot of flexibility to determine exactly what it means to us. Most of that is in the hands of the existing maintainers of LibSass, Node Sass, and related tools.

The core team's hope is that the maintainers of these packages can continue to maintain them at least enough to fix critical bugs and address any security issues that come up. In this case, "deprecated" would mean "we don't expect to release any new features or support new CSS specs, but existing SCSS will continue to run." Ideally you would provide a time horizon where maintenance is assured, giving users a clear timeline to migrate away.

What about portability and performance?

LibSass today has two major benefits over Dart Sass:

• Portability: since it's written in C++, it's easy to embed LibSass within other programming languages and provide a native-feeling API.

• Performance: calling out to LibSass via the C++ API is very fast relative to the speeds of code written directly in scripting languages. In particular, this means LibSass is substantially faster in JavaScript than Dart Sass-compiled-to-JS (although it's comparable to Dart Sass's command-line executable).

We're working on addressing both of those with the Sass embedded protocol, which runs a Sass compiler as a subprocess that communicates with the host language via message-passing. The embedded protocol supports all the features of a native Sass API, including the ability to define custom importers and Sass functions, while also providing the high performance of the CLI app. Dart Sass has already implemented the compiler side of the embedded protocol, and we intend to launch a JavaScript host for it within the next couple months.

What do we do now?

The immediate next step is to coordinate how we want to mark the LibSass and Node Sass repositories as "deprecated". This should include adding a notification to a prominent spot in the READMEs and, for Node Sass, deprecating the npm package. I also plan to write a post for the Sass blog, which I'd like to post concurrently with these deprecations landing.

Thank you

Finally, I want to thank everyone who's put so much time and energy into LibSass and Node Sass over the years. It will always be a towering achievement, and Sass's popularity outside of the Ruby community is undoubtedly due in large part to its existence. Many people have tried to implement Sass only to find that the language is much deeper and more complex than they expected, and LibSass alone among all of those implementations managed to become fully-featured enough to provide real value for thousands if not millions of users. You deserve to be proud of that work, and I hope you still consider yourselves part of the Sass community going forward.

[mangelozzi]

Thanks guys for your hardwork. SASS really does make CSS fun again, much appreciated!! I would like to encourage you guys to announce this sooner than later. After spending 2 days on writing custom code with libsass, and checking the state of @use after a few years, I had a hunch and googled "is libsass depricated" and found this. Now about to bin the last 3 days of code and start again. Hopefully other people avoid this scenario with an announcement soon.
Thanks again!! =)