sass-site/source/blog/027-libsass-is-deprecated.md

title	author	tags	date
LibSass is Deprecated	Natalie Weizenbaum	blog	2020-10-26 12:00:00 -8

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). As much as we've hoped to see this pattern turn around, even the excellent work of long-time LibSass contributors Michael Mifsud and Marcel Greter couldn't keep up with the fast pace of language development in both CSS and Sass.

I'll go into detail about what this means below, but here are the major points:

• We no longer recommend LibSass for new Sass projects. Use Dart Sass instead.

• We recommend all existing LibSass users make plans to eventually move onto Dart Sass, and that all Sass libraries make plans to eventually drop support for LibSass.

• We're no longer planning to add any new features to LibSass, including compatibility with new CSS features.

• LibSass and Node Sass will continue to be maintained indefinitely on a best-effort basis, including fixing major bugs and security issues and maintaining compatibility with the latest Node versions.

Why deprecate?

For several years now, Sass has managed to exist in an ambiguous kind of state where LibSass was an officially-supported implementation in theory, but its feature surface was static in practice. As time has gone on, it's becoming increasingly clear that this state causes substantial concrete problems for Sass users. For example, 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.

Official support for LibSass doesn't just cause pain for individual users. Because LibSass doesn't support the Sass module system that launched last year, major shared Sass libraries have been unable to use it for fear that their downstream users would be incompatible. By clearly indicating that all Sass users should eventually move off of LibSass, we hope to make it more feasible for these library authors to use more modern features.

LibSass has even inhibited the development of the Sass language itself. We've been unable to move forward with the proposal for treating / as a separator because any code they'd write would either produce deprecation warnings in Dart Sass or fail to compile in LibSass. By marking LibSass as deprecated, this becomes much more feasible, and Sass becomes much better at supporting the latest versions of CSS.

What does "deprecated" mean?

We're choosing to use the term "deprecated" because it carries a lot of weight in the programming community, and provides a strong signal that users should start planning to move away from LibSass. However, it doesn't mean that the project is entirely dead. Michael Mifsud, the lead maintainer of LibSass and Node Sass, has affirmed that he plans to continue maintenance on the same level as the past few years. This means that although there will be no more features added (and as such LibSass will slowly drift further and further out of compatibility with the latest CSS and Sass syntax), there will continue to be maintenance releases indefinitely.

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 can communicate with any 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 a JavaScript host for it is in active development.

How do I migrate?

If you're a user of Node Sass, migrating to Dart Sass is straightforward: just replace node-sass in your package.json file with sass. Both packages expose the same JavaScript API.

If you're using the SassC command-line interface, you can switch to Dart Sass's CLI. Note that this doesn't have exactly the same interface as SassC, so you may need to change a few flags.

If you're using LibSass through a wrapper library in another language, you can either switch to the Dart Sass CLI or ask the maintainer of the LibSass wrapper to convert it to a host for the Sass embedded protocol. The embedded protocol allows any language to provide a native API that calls out to Dart Sass.

Please note that because activity on LibSass has been low for several years, it has a number of outstanding bugs and behavioral variations from the Sass spec. You may need to make minor updates to stylesheets to make them compatible with Dart Sass. See this list of major compatibility issues for reference.

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. These maintainers deserve to be proud of that work, and I hope they'll always consider themselves part of the Sass community going forward.