Back in 2019, we released the Sass module system, adding new @use and@forward rules to the language that were designed to replace @import andmake stylesheets more maintainable and less error-prone. We can now announcethat @import is officially deprecated as of Dart Sass 1.80.0.The module system ensures that it's easy for both developers and tooling todetermine where a given Sass member is defined, adds namespacing to prevent theneed to manually add long, awkward namespaces to names, and allows libraryauthors to ensure their private helpers can't be accessed by downstream users.Additionally, since each module is only ever loaded once, depending on the samestylesheet multiple times no longer results in duplicated CSS.With 4.5 years since we released the module system and more than a year sincewe passed the 80% Dart Sass usage share threshold we set for starting thisdeprecation, we feel comfortable making this move. However, we understand thatthis is a big change to the language and not a

Wide gamut colors are coming to Sass!I should clarify. Wide gamut CSS color formats like oklch(…) and color(display-p3 …) have been available in all major browsers since May, 2023. But even before that, these new color formats were allowed in Sass. This is one of my favorite features of Sass: most new CSS just works, without any need for "official" support or updates. When Sass encounters unknown CSS, it passes that code along to the browser. Not everything needs to be pre-processed.Often, that's all we need. When Cascade Layers and Container Queries rolled out in browsers, there was nothing more for Sass to do. But the new CSS color formats are a bit different. Since colors are a first-class data type in Sass, we don't always want to pass them along as-is. We often want to manipulate and manage colors before they go to the browser.Already know all about color spaces? Skip ahead to the new Sass features!The color format trade-offThe color format trade-off permalinkCSS has historically

The time has finally come to retire Node Sass. This Node.js wrapper for LibSasswas the first official Sass compiler available in the JavaScript ecosystem andwas a huge part of Sass growing beyond the scope of the Ruby community where itoriginated, but it hasn't received a new release in a year and a half and themost recent set of maintainers no longer have the bandwidth to continue updatingit.The npm package has been marked as deprecated, and the GitHub repository hasbeen archived to mitigate confusion about which Sass repositories are stillbeing developed. If you're still using Node Sass, we strongly recommend you takethis opportunity to migrate to the primary implementation, Dart Sass, instead.The LibSass implementation that Node Sass used remains deprecated but not yetend-of-life, as its maintainer Marcel Greter continues to make occasional fixes.However, there is no longer an officially-supported way to use thisimplementation from Node.js.I want to take this opportunity to thank ev

Several months ago, we asked for feedback on a proposal for a new standard forimporters that could load packages from various different package managers usingthe shared pkg: scheme, as well as a built-in pkg: importer that supportsNode.js's module resolution algorithm. Today, I'm excited to announce that thisfeature has shipped in Dart Sass 1.71.0!No longer will you have to manually add node_modules to your loadPathsoption and worry about whether nested packages will work at all. No longer willyou need to add ~s to your URLs and give up all portability. Now you can justpass importers: [new NodePackageImporter()] and write @use 'pkg:library' andit'll work just how you want out of the box.What is a pkg: importer?What is a pkg: importer? permalinkThink of a pkg: importer like a specification that anyone can implement bywriting a custom importer that follows a few rules. We've implemented one forthe Node.js module algorithm, but you could implement one that loads Sass filesfrom RubyGems or

Sass users often need to use styles from a dependency to customize an existingtheme or access styling utilities. Historically, Sass has not specified astandard method for using packages from dependencies. This has led to a varietyof domain-specific solutions, including the ~ prefix in Webpack, and addingnode_modules to loadPaths.This has been a common pain point, and can make it difficult to rely ondependencies. It can also make it more difficult to move your project to a newbuild process.Package ImportersPackage Importers permalinkWe are proposing a new type of importer that allows users to use the pkg: URLscheme to direct Sass to resolve the dependency URL using the resolutionstandards and conventions for a specific environment.To address the largest use case, we are proposing a built-in Package Importerfor the Node ecosystem. Our recommendation is for package authors to define asass conditional export for entry points to their package in theirdistributed package.json. For example, a

Over Sass's lifetime, we've seen many of the features we've pioneered adopted inthe browser. CSS variables, math functions, and most recently nesting wereall inspired by Sass. But running Sass itself as a compiler in the browser wasnever possible... until now.With the release of Dart Sass 1.63, we're officially adding support to thesass npm package for running directly in the browser. No longer do creators ofplaygrounds or web IDEs need to make server calls to compile their Sass. Now youcan just load it up and use it right on your very page.You can try it right now, in fact! Just open up your developer console and runthis:const sass = await import('https://jspm.dev/sass');sass.compileString('a {color: #663399}');How Else Can I Use It?How Else Can I Use It? permalinkWe've done our best to make sure that Sass in the browser is usable as many waysas possible. It can be loaded using both CommonJS require() and ES6import. It can be loaded by bundlers (we've tested with esbuild, Rollup,Vite,