Sass Blog

Page 1 of 9

• `@import` is Deprecated

  Posted 17 October 2024 by Jennifer Thakar

  Back in 2019, we released the Sass module system, adding new @use and @forward rules to the language that were designed to replace @import and make stylesheets more maintainable and less error-prone. We can now announce that @import is officially deprecated as of Dart Sass 1.80.0.

  The module system ensures that it’s easy for both developers and tooling to determine where a given Sass member is defined, adds namespacing to prevent the need to manually add long, awkward namespaces to names, and allows library authors to ensure their private helpers can’t be accessed by downstream users. Additionally, since each module is only ever loaded once, depending on the same stylesheet multiple times no longer results in duplicated CSS.

  With 4.5 years since we released the module system and more than a year since we passed the 80% Dart Sass usage share threshold we set for starting this deprecation, we feel comfortable making this move. However, we understand that this is a big change to the language and not all…

• Sass color spaces & wide gamut colors

  Posted 11 September 2024 by Miriam Suzanne

  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…

• Node Sass is end-of-life

  Posted 24 July 2024 by Natalie Weizenbaum

  The time has finally come to retire Node Sass. This Node.js wrapper for LibSass was the first official Sass compiler available in the JavaScript ecosystem and was a huge part of Sass growing beyond the scope of the Ruby community where it originated, but it hasn’t received a new release in a year and a half and the most recent set of maintainers no longer have the bandwidth to continue updating it.

  The npm package has been marked as deprecated, and the GitHub repository has been archived to mitigate confusion about which Sass repositories are still being developed. If you’re still using Node Sass, we strongly recommend you take this opportunity to migrate to the primary implementation, Dart Sass, instead.

  The LibSass implementation that Node Sass used remains deprecated but not yet end-of-life, as its maintainer Marcel Greter continues to make occasional fixes. However, there is no longer an officially-supported way to use this implementation from Node.js.

  I want to take this opportunity to thank everyone who used Node…

• Announcing `pkg:` Importers

  Posted 16 February 2024 by Natalie Weizenbaum

  Several months ago, we asked for feedback on a proposal for a new standard for importers that could load packages from various different package managers using the shared pkg: scheme, as well as a built-in pkg: importer that supports Node.js’s module resolution algorithm. Today, I’m excited to announce that this feature has shipped in Dart Sass 1.71.0!

  No longer will you have to manually add node_modules to your loadPaths option and worry about whether nested packages will work at all. No longer will you need to add ~s to your URLs and give up all portability. Now you can just pass importers: [new NodePackageImporter()] and write @use 'pkg:library' and it’ll work just how you want out of the box.

  What is a pkg: importer?What is a pkg: importer? permalink

  Think of a pkg: importer like a specification that anyone can implement by writing a custom importer that follows a few rules. We’ve implemented one for the Node.js module algorithm, but you could implement one that loads Sass…

• Request for Comments: Package Importer

  Posted 26 September 2023 by James Stuckey Weber

  Sass users often need to use styles from a dependency to customize an existing theme or access styling utilities. Historically, Sass has not specified a standard method for using packages from dependencies. This has led to a variety of domain-specific solutions, including the ~ prefix in Webpack, and adding node_modules to loadPaths.

  This has been a common pain point, and can make it difficult to rely on dependencies. It can also make it more difficult to move your project to a new build process.

  Package ImportersPackage Importers permalink

  We are proposing a new type of importer that allows users to use the pkg: URL scheme to direct Sass to resolve the dependency URL using the resolution standards and conventions for a specific environment.

  To address the largest use case, we are proposing a built-in Package Importer for the Node ecosystem. Our recommendation is for package authors to define a sass conditional export for entry points to their package in their distributed package.json. For example, a package.json containing:…

Next page