{"id":296858,"date":"2019-10-07T07:24:56","date_gmt":"2019-10-07T14:24:56","guid":{"rendered":"https:\/\/css-tricks.com\/?p=296858"},"modified":"2019-10-14T11:06:17","modified_gmt":"2019-10-14T18:06:17","slug":"introducing-sass-modules","status":"publish","type":"post","link":"https:\/\/css-tricks.com\/introducing-sass-modules\/","title":{"rendered":"Introducing Sass Modules"},"content":{"rendered":"<p>Sass just launched a major new feature you might recognize from other languages: <strong>a module system<\/strong>. This is a big step forward for <code>@import<\/code>. one of the most-used Sass-features. While the current <code>@import<\/code> rule allows you to pull in third-party packages, and split your Sass into manageable &#8220;partials,&#8221; it has a few limitations:<\/p>\n<ul>\n<li><code>@import<\/code> is also a CSS feature, and the differences can be confusing<\/li>\n<li>If you <code>@import<\/code> the same file multiple times, it can slow down compilation, cause override conflicts, and generate duplicate output.<\/li>\n<li>Everything is in the global namespace, including third-party packages \u2013 so my <code>color()<\/code> function might override your existing <code>color()<\/code> function, or vice versa.<\/li>\n<li>When you use a function like <code>color()<\/code>. it\u2019s impossible to know exactly where it was defined. Which <code>@import<\/code> does it come from?<\/li>\n<\/ul>\n<p>Sass package authors (like me) have tried to work around the namespace issues by manually prefixing our variables and functions \u2014 but Sass modules are a much more powerful solution. In brief, <code>@import<\/code> is being replaced with more explicit <code>@use<\/code> and <code>@forward<\/code> rules. Over the next few years Sass <code>@import<\/code> will be deprecated, and then removed. You can still use <a href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/Web\/CSS\/@import\" rel=\"noopener\">CSS imports<\/a>, but they won\u2019t be compiled by Sass. Don\u2019t worry, there\u2019s a <a href=\"http:\/\/sass-lang.com\/documentation\/cli\/migrator\" rel=\"noopener\">migration tool<\/a> to help you upgrade!<\/p>\n<p><!--more--><\/p>\n<h3>Import files with @use<\/h3>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'buttons';<\/code><\/pre>\n<p>The new <code>@use<\/code> is similar to <code>@import<\/code>. but has some notable differences:<\/p>\n<ul>\n<li>The file is only imported once, no matter how many times you <code>@use<\/code> it in a project.<\/li>\n<li>Variables, mixins, and functions (what Sass calls &#8220;members&#8221;) that start with an underscore (<code>_<\/code>) or hyphen (<code>-<\/code>) are considered private, and not imported.<\/li>\n<li>Members from the used file (<code>buttons.scss<\/code> in this case) are only made available locally, but not passed along to future imports.<\/li>\n<li>Similarly, <code>@extends<\/code> will only apply <em>up the chain;<\/em> extending selectors in imported files, but not extending files that import this one.<\/li>\n<li>All imported members are <em>namespaced by default<\/em>.<\/li>\n<\/ul>\n<p>When we <code>@use<\/code> a file, Sass automatically generates a namespace based on the file name:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'buttons'; \/\/ creates a `buttons` namespace\r\n@use 'forms'; \/\/ creates a `forms` namespace<\/code><\/pre>\n<p>We now have access to members from both <code>buttons.scss<\/code> and <code>forms.scss<\/code> \u2014 but that access is not transferred between the imports: <code>forms.scss<\/code> still has no access to the variables defined in <code>buttons.scss<\/code>. Because the imported features are namespaced, we have to use a new period-divided syntax to access them:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ variables: &lt;namespace&gt;.$variable\r\n$btn-color: buttons.$color;\r\n$form-border: forms.$input-border;\r\n\r\n\/\/ functions: &lt;namespace&gt;.function()\r\n$btn-background: buttons.background();\r\n$form-border: forms.border();\r\n\r\n\/\/ mixins: @include &lt;namespace&gt;.mixin()\r\n@include buttons.submit();\r\n@include forms.input();<\/code><\/pre>\n<p>We can change or remove the default namespace by adding <code>as &lt;name&gt;<\/code> to the import:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'buttons' as *; \/\/ the star removes any namespace\r\n@use 'forms' as f;\r\n\r\n$btn-color: $color; \/\/ buttons.$color without a namespace\r\n$form-border: f.$input-border; \/\/ forms.$input-border with a custom namespace<\/code><\/pre>\n<p>Using <code>as *<\/code> adds a module to the root namespace, so no prefix is required, but those members are still locally scoped to the current document.<\/p>\n<h3>Import built-in Sass modules<\/h3>\n<p>Internal Sass features have also moved into the module system, so we have complete control over the global namespace. There are several built-in modules \u2014 <code>math<\/code>, <code>color<\/code>, <code>string<\/code>, <code>list<\/code>, <code>map<\/code>, <code>selector<\/code>, and <code>meta<\/code> \u2014 which have to be imported explicitly in a file before they are used:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'sass:math';\r\n$half: math.percentage(1\/2);<\/code><\/pre>\n<p>Sass modules can also be imported to the global namespace:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'sass:math' as *;\r\n$half: percentage(1\/2);<\/code><\/pre>\n<p>Internal functions that already had prefixed names, like <code>map-get<\/code> or <code>str-index<\/code>. can be used without duplicating that prefix:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'sass:map';\r\n@use 'sass:string';\r\n$map-get: map.get(('key': 'value'), 'key');\r\n$str-index: string.index('string', 'i');<\/code><\/pre>\n<p>You can find a full list of built-in modules, functions, and name changes in the <a href=\"https:\/\/github.com\/sass\/sass\/blob\/master\/accepted\/module-system.md#built-in-modules-1\" rel=\"noopener\">Sass module specification<\/a>.<\/p>\n<h3>New and changed core features<\/h3>\n<p>As a side benefit, this means that Sass can safely add new internal mixins and functions without causing name conflicts. The most exciting example in this release is a <code>sass:meta<\/code> mixin called <code>load-css()<\/code>. This works similar to <code>@use<\/code> but it only returns generated CSS output, and it can be used dynamically anywhere in our code:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'sass:meta';\r\n$theme-name: 'dark';\r\n\r\n[data-theme='#{$theme-name}'] {\r\n  @include meta.load-css($theme-name);\r\n}<\/code><\/pre>\n<p>The first argument is a module URL (like <code>@use<\/code>) but it can be dynamically changed by variables, and even include interpolation, like <code>theme-#{$name}<\/code>. The second (optional) argument accepts a map of configuration values:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ Configure the $base-color variable in 'theme\/dark' before loading\r\n@include meta.load-css(\r\n  'theme\/dark', \r\n  $with: ('base-color': rebeccapurple)\r\n);<\/code><\/pre>\n<p>The <code>$with<\/code> argument accepts configuration keys and values for any variable in the loaded module, if it is both: <\/p>\n<ul>\n<li>A global variable that doesn\u2019t start with <code>_<\/code> or <code>-<\/code> (now used to signify privacy)<\/li>\n<li>Marked as a <code>!default<\/code> value, to be configured<\/li>\n<\/ul>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ theme\/_dark.scss\r\n$base-color: black !default; \/\/ available for configuration\r\n$_private: true !default; \/\/ not available because private\r\n$config: false; \/\/ not available because not marked as a !default<\/code><\/pre>\n<p>Note that the <code>'base-color'<\/code> key will set the <code>$base-color<\/code> variable.<\/p>\n<p>There are two more <code>sass:meta<\/code> functions that are new: <code>module-variables()<\/code> and <code>module-functions()<\/code>. Each returns a map of member names and values from an already-imported module. These accept a single argument matching the module namespace:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'forms';\r\n\r\n$form-vars: module-variables('forms');\r\n\/\/ (\r\n\/\/   button-color: blue,\r\n\/\/   input-border: thin,\r\n\/\/ )\r\n\r\n$form-functions: module-functions('forms');\r\n\/\/ (\r\n\/\/   background: get-function('background'),\r\n\/\/   border: get-function('border'),\r\n\/\/ )<\/code><\/pre>\n<p>Several other <code>sass:meta<\/code> functions \u2014 <code>global-variable-exists()<\/code>, <code>function-exists()<\/code>, <code>mixin-exists()<\/code>, and <code>get-function()<\/code> \u2014 will get additional <code>$module<\/code> arguments, allowing us to inspect each namespace explicitly. <\/p>\n<h4>Adjusting and scaling colors<\/h4>\n<p>The <code>sass:color<\/code> module also has some interesting caveats, as we try to move away from some legacy issues. Many of the legacy shortcuts like <code>lighten()<\/code>. or <code>adjust-hue()<\/code> are deprecated for now in favor of explicit <code>color.adjust()<\/code> and <code>color.scale()<\/code> functions:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ previously lighten(red, 20%)\r\n$light-red: color.adjust(red, $lightness: 20%);\r\n\r\n\/\/ previously adjust-hue(red, 180deg)\r\n$complement: color.adjust(red, $hue: 180deg);<\/code><\/pre>\n<p>Some of those old functions (like <code>adjust-hue<\/code>) are redundant and unnecessary. Others \u2014  like <code>lighten<\/code>. <code>darken<\/code>. <code>saturate<\/code>. and so on \u2014 need to be re-built with better internal logic. The original functions were based on <code>adjust()<\/code>. which uses linear math: adding <code>20%<\/code> to the current lightness of <code>red<\/code> in our example above. In most cases, we actually want to <code>scale()<\/code> the lightness by a percentage, relative to the current value:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ 20% of the distance to white, rather than current-lightness + 20\r\n$light-red: color.scale(red, $lightness: 20%);<\/code><\/pre>\n<p>Once fully deprecated and removed, these shortcut functions will eventually re-appear in <code>sass:color<\/code> with new behavior based on <code>color.scale()<\/code> rather than <code>color.adjust()<\/code>.  This is happening in stages to avoid sudden backwards-breaking changes. In the meantime, I recommend manually checking your code to see where <code>color.scale()<\/code> might work better for you.<\/p>\n<h3>Configure imported libraries<\/h3>\n<p>Third-party or re-usable libraries will often come with default global configuration variables for you to override. We used to do that with variables before an import:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ _buttons.scss\r\n$color: blue !default;\r\n\r\n\/\/ old.scss\r\n$color: red;\r\n@import 'buttons';<\/code><\/pre>\n<p>Since used modules no longer have access to local variables, we need a new way to set those defaults. We can do that by adding a configuration map to <code>@use<\/code>:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@use 'buttons' with (\r\n  $color: red,\r\n  $style: 'flat',\r\n);<\/code><\/pre>\n<p>This is similar to the <code>$with<\/code> argument in <code>load-css()<\/code>. but rather than using variable-names as keys, we use the variable itself, starting with <code>$<\/code>. <\/p>\n<p>I love how explicit this makes configuration, but there\u2019s one rule that has tripped me up several times: <strong>a module can only be configured once, the first time it is used<\/strong>. Import order has always been important for Sass, even with <code>@import<\/code>. but those issues always failed silently. Now we get an explicit error, which is both good and sometimes surprising. Make sure to <code>@use<\/code> and configure libraries first thing in any &#8220;entrypoint&#8221; file (the central document that imports all partials), so that those configurations compile before other <code>@use<\/code> of the libraries.<\/p>\n<p>It\u2019s (currently) impossible to &#8220;chain&#8221; configurations together while keeping them editable, but you can wrap a configured module along with extensions, and pass that along as a new module.<\/p>\n<h3>Pass along files with @forward<\/h3>\n<p>We don\u2019t always need to use a file, and access its members. Sometimes we just want to pass it along to future imports. Let\u2019s say we have multiple form-related partials, and we want to import all of them together as one namespace. We can do that with <code>@forward<\/code>:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ forms\/_index.scss\r\n@forward 'input';\r\n@forward 'textarea';\r\n@forward 'select';\r\n@forward 'buttons';<\/code><\/pre>\n<p>Members of the forwarded files are not available in the current document and no namespace is created, but those variables, functions, and mixins will be available when another file wants to <code>@use<\/code> or <code>@forward<\/code> the entire collection. If the forwarded partials contain actual CSS, that will also be passed along without generating output until the package is used. At that point it will all be treated as a single module with a single namespace:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ styles.scss\r\n@use 'forms'; \/\/ imports all of the forwarded members in the `forms` namespace<\/code><\/pre>\n<p class=\"explanation\"><strong>Note:<\/strong> if you ask Sass to import a directory, it will look for a file named <code>index<\/code> or <code>_index<\/code>)<\/p>\n<p>By default, all public members will forward with a module. But we can be more selective by adding <code>show<\/code> or <code>hide<\/code> clauses, and naming specific members to include or exclude:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ forward only the 'input' border() mixin, and $border-color variable\r\n@forward 'input' show border, $border-color;\r\n\r\n\/\/ forward all 'buttons' members *except* the gradient() function\r\n@forward 'buttons' hide gradient;<\/code><\/pre>\n<p class=\"explanation\"><strong>Note:<\/strong> when functions and mixins share a name, they are shown and hidden together.<\/p>\n<p>In order to clarify source, or avoid naming conflicts between forwarded modules, we can use <code>as<\/code> to prefix members of a partial as we forward:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ forms\/_index.scss\r\n\/\/ @forward \"&lt;url&gt;\" as &lt;prefix&gt;-*;\r\n\/\/ assume both modules include a background() mixin\r\n@forward 'input' as input-*;\r\n@forward 'buttons' as btn-*;\r\n\r\n\/\/ style.scss\r\n@use 'forms';\r\n@include forms.input-background();\r\n@include forms.btn-background();<\/code><\/pre>\n<p>And, if we need, we can always <code>@use<\/code> and <code>@forward<\/code> the same module by adding both rules:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">@forward 'forms';\r\n@use 'forms';<\/code><\/pre>\n<p>That\u2019s particularly useful if you want to wrap a library with configuration or any additional tools, before passing it along to your other files. It can even help simplify import paths:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ _tools.scss\r\n\/\/ only use the library once, with configuration\r\n@use 'accoutrement\/sass\/tools' with (\r\n  $font-path: '..\/fonts\/',\r\n);\r\n\/\/ forward the configured library with this partial\r\n@forward 'accoutrement\/sass\/tools';\r\n\r\n\/\/ add any extensions here...\r\n\r\n\r\n\/\/ _anywhere-else.scss\r\n\/\/ import the wrapped-and-extended library, already configured\r\n@use 'tools';<\/code><\/pre>\n<p>Both <code>@use<\/code> and <code>@forward<\/code> must be declared at the root of the document (not nested), and at the start of the file. Only <code>@charset<\/code> and simple variable definitions can appear before the import commands.<\/p>\n<h3>Moving to modules<\/h3>\n<p>In order to test the new syntax, I built a new open source Sass library (<a href=\"https:\/\/github.com\/mirisuzanne\/cascading-colors\/\" rel=\"noopener\">Cascading Color Systems<\/a>) and a <a href=\"https:\/\/github.com\/mirisuzanne\/teacup\" rel=\"noopener\">new website for my band<\/a> \u2014 both still under construction. I wanted to understand modules as both a library and website author. Let\u2019s start with the &#8220;end user&#8221; experience of writing site styles with the module syntax\u2026<\/p>\n<h4>Maintaining and writing styles<\/h4>\n<p>Using modules on the website was a pleasure. The new syntax encourages a code architecture that I already use. All my global configuration and tool imports live in a single directory (I call it <code>config<\/code>), with an index file that forwards everything I need:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ config\/_index.scss\r\n@forward 'tools';\r\n@forward 'fonts';\r\n@forward 'scale';\r\n@forward 'colors';<\/code><\/pre>\n<p>As I build out other aspects of the site, I can import those tools and configurations wherever I need them:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ layout\/_banner.scss\r\n@use '..\/config';\r\n\r\n.page-title {\r\n  @include config.font-family('header');\r\n}<\/code><\/pre>\n<p>This even works with my existing Sass libraries, like <a href=\"https:\/\/www.oddbird.net\/accoutrement\/\" rel=\"noopener\">Accoutrement<\/a> and <a href=\"https:\/\/www.oddbird.net\/herman\/\" rel=\"noopener\">Herman<\/a>, that still use the old <code>@import<\/code> syntax. Since the <code>@import<\/code> rule will not be replaced everywhere overnight, Sass has built in a transition period. Modules are available now, but <code>@import<\/code> will not be deprecated for another year or two \u2014 and only removed from the language a year after that. In the meantime, the two systems will work together in either direction:<\/p>\n<ul>\n<li>If we <code>@import<\/code> a file that contains the new <code>@use<\/code>\/<code>@forward<\/code> syntax, only the public members are imported, without namespace.<\/li>\n<li>If we <code>@use<\/code> or <code>@forward<\/code> a file that contains legacy <code>@import<\/code> syntax, we get access to all the nested imports as a single namespace.<\/li>\n<\/ul>\n<p>That means you can start using the new module syntax right away, without waiting for a new release of your favorite libraries: and I can take some time to update all my libraries!<\/p>\n<h4>Migration tool<\/h4>\n<p>Upgrading shouldn\u2019t take long if we use the <a href=\"https:\/\/sass-lang.com\/documentation\/cli\/migrator\" rel=\"noopener\">Migration Tool<\/a> built by Jennifer Thakar. It can be installed with Node, Chocolatey, or Homebrew:<\/p>\n<pre rel=\"Terminal\"><code class=\"language-javascript\">npm install -g sass-migrator\r\nchoco install sass-migrator\r\nbrew install sass\/sass\/migrator<\/code><\/pre>\n<p>This is not a single-use tool for migrating to modules. Now that Sass is back in active development (see below), the migration tool will also get regular updates to help migrate each new feature. It\u2019s a good idea to install this globally, and keep it around for future use.<\/p>\n<p>The migrator can be run from the command line, and will hopefully be added to <a href=\"http:\/\/modules.sass-lang.com\/install\" rel=\"noopener\">third-party applications<\/a> like CodeKit and Scout as well. Point it at a single Sass file, like <code>style.scss<\/code>. and tell it what migration(s) to apply. At this point there\u2019s only one migration called <code>module<\/code>:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\"># sass-migrator &lt;migration&gt; &lt;entrypoint.scss...&gt;\r\nsass-migrator module style.scss<\/code><\/pre>\n<p>By default, the migrator will only update a single file, but in most cases we\u2019ll want to update the main file <em>and all its dependencies<\/em>: any partials that are imported, forwarded, or used. We can do that by mentioning each file individually, or by adding the <code>--migrate-deps<\/code> flag:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">sass-migrator --migrate-deps module style.scss<\/code><\/pre>\n<p>For a test-run, we can add <code>--dry-run --verbose<\/code> (or <code>-nv<\/code> for short), and see the results without changing any files. There are a number of other options that we can use to customize the migration \u2014 even one specifically for helping library authors remove old manual namespaces \u2014 but I won\u2019t cover all of them here. The <a href=\"https:\/\/sass-lang.com\/documentation\/cli\/migrator\" rel=\"noopener\">migration tool is fully documented<\/a> on the <a href=\"http:\/\/sass-lang.com\" rel=\"noopener\">Sass website<\/a>.<\/p>\n<h4>Updating published libraries<\/h4>\n<p>I ran into a few issues on the library side, specifically trying to make user-configurations available across multiple files, and working around the missing chained-configurations. The ordering errors can be difficult to debug, but the results are worth the effort, and I think we\u2019ll see some additional patches coming soon. I still have to experiment with the migration tool on complex packages, and possibly write a follow-up post for library authors. <\/p>\n<p>The important thing to know right now is that Sass has us covered during the transition period. Not only can imports and modules work together, but we can create &#8220;<a href=\"http:\/\/sass-lang.com\/documentation\/at-rules\/import#import-only-files\" rel=\"noopener\">import-only<\/a>&#8221; files to provide a better experience for legacy users still <code>@import<\/code>ing our libraries. In most cases, this will be an alternative version of the main package file, and you\u2019ll want them side-by-side: <code>&lt;name&gt;.scss<\/code> for module users, and <code>&lt;name&gt;.import.scss<\/code> for legacy users. Any time a user calls <code>@import &lt;name&gt;<\/code>, it will load the <code>.import<\/code> version of the file:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ load _forms.scss\r\n@use 'forms';\r\n\r\n\/\/ load _forms.input.scss\r\n@import 'forms';<\/code><\/pre>\n<p>This is particularly useful for adding prefixes for non-module users:<\/p>\n<pre rel=\"SCSS\"><code class=\"language-scss\">\/\/ _forms.import.scss\r\n\/\/ Forward the main module, while adding a prefix\r\n@forward \"forms\" as forms-*;<\/code><\/pre>\n<h3>Upgrading Sass<\/h3>\n<p>You may remember that Sass had a feature-freeze a few years back, to get various implementations (LibSass, Node Sass, Dart Sass) all caught up, and eventually <a href=\"https:\/\/css-tricks.com\/ruby-sass-to-be-put-to-pasture-on-march-26-2019\/\">retired the original Ruby implementation<\/a>. That freeze ended last year, with several new features and active <a href=\"https:\/\/github.com\/sass\/sass\" rel=\"noopener\">discussions and development<\/a> on GitHub \u2013 but not much fanfare. If you missed those releases, you can get caught up on the <a href=\"http:\/\/sass.logdown.com\/\" rel=\"noopener\">Sass Blog<\/a>:<\/p>\n<ul>\n<li><a href=\"http:\/\/sass.logdown.com\/posts\/7807041-feature-watchcss-imports-and-css-compatibility\" rel=\"noopener\">CSS Imports and CSS Compatibility<\/a> (Dart Sass v1.11)<\/li>\n<li><a href=\"http:\/\/sass.logdown.com\/posts\/7816585-feature-watchcontent-arguments-and-color-function-syntax\" rel=\"noopener\">Content Arguments and Color Functions<\/a> (Dart Sass v1.15)<\/li>\n<\/ul>\n<p>Dart Sass is now the canonical implementation, and will generally be the first to implement new features. If you want the latest, I recommend making the switch. You can <a href=\"http:\/\/sass-lang.com\/install\" rel=\"noopener\">install Dart Sass<\/a> with Node, Chocolatey, or Homebrew. It also works great with existing <a href=\"https:\/\/www.npmjs.com\/package\/gulp-sass\" rel=\"noopener\">gulp-sass<\/a> build steps.<\/p>\n<p>Much like CSS (since CSS3), there is no longer a single unified version-number for new releases. All Sass implementations are working from the same specification, but each one has a unique release schedule and numbering, reflected with support information in the <a href=\"https:\/\/sass-lang.com\/documentation\" rel=\"noopener\">beautiful new documentation<\/a> designed by <a href=\"https:\/\/www.sushiandrobots.com\/\" rel=\"noopener\">Jina<\/a>.<\/p>\n<figure id=\"post-296871\" class=\"align-left media-296871\"><img decoding=\"async\" src=\"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/10\/sass-modules-01.png?ssl=1\" alt=\"\" data-recalc-dims=\"1\" \/><\/figure>\n<p>Sass Modules are available as of <strong>October 1st, 2019<\/strong> in <strong>Dart Sass 1.23.0<\/strong>.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Sass just launched a major new feature you might recognize from other languages: a module system. This is a big step forward for @import. one of the most-used Sass-features. While the current @import rule allows you to pull in third-party packages, and split your Sass into manageable &#8220;partials,&#8221; it has a few limitations: @import is [&hellip;]<\/p>\n","protected":false},"author":245622,"featured_media":296874,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_bbp_topic_count":0,"_bbp_reply_count":0,"_bbp_total_topic_count":0,"_bbp_total_reply_count":0,"_bbp_voice_count":0,"_bbp_anonymous_reply_count":0,"_bbp_topic_count_hidden":0,"_bbp_reply_count_hidden":0,"_bbp_forum_subforum_count":0,"sig_custom_text":"","sig_image_type":"featured-image","sig_custom_image":0,"sig_is_disabled":false,"inline_featured_image":false,"c2c_always_allow_admin_comments":false,"footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":[]},"categories":[4],"tags":[845,476],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/10\/sass-sparkles.png?fit=1200%2C600&ssl=1","jetpack-related-posts":[],"featured_media_src_url":"https:\/\/i0.wp.com\/css-tricks.com\/wp-content\/uploads\/2019\/10\/sass-sparkles.png?fit=1024%2C512&ssl=1","_links":{"self":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/296858"}],"collection":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/users\/245622"}],"replies":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/comments?post=296858"}],"version-history":[{"count":11,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/296858\/revisions"}],"predecessor-version":[{"id":297292,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/posts\/296858\/revisions\/297292"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media\/296874"}],"wp:attachment":[{"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/media?parent=296858"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/categories?post=296858"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/css-tricks.com\/wp-json\/wp\/v2\/tags?post=296858"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}