ooh, thanks. we were just about to get to this

We don't currently use any use syntax in our sass now. It looks like math.div is only available in the new syntax — will that cause any breaking compatibility issues?

If we do this, it will be a breaking change for anyone who does something like compiles with the built-in Jekyll compiler. I guess we've known this day was coming for some time, but we're pushing against the requirements of modern Sass and the limitations of the Sass ecosystem

Jekyll 4.0 and up uses sass. Assuming you'll want to do some testing/research.

Also, could consider publishing as a release candidate or beta release and asking folks to test it 🔬

What about offering the opposite of https://sass-lang.com/documentation/breaking-changes/slash-div#automatic-migration if it causes any issues, i.e. a de-migrator

@maya I found that trying to use modern Sass syntax with Jekyll 4.2.0 resulted in a compile error. Have you successfully used module syntax with native Jekyll?

It looks like Jekyll uses LibSass in their Jekyll-sass-converter plugin, so it would not work with their out-of-box Sass processing. Is that what you're using for your Jekyll projects?

It's not what we're using, but it is somewhat common

@thisisdano Another developer I chatted with gave some good advice:

we’re in this situation and have opted to have a period of time where we’re offering both options before introducing the breaking change to cut over to @use entirely. So - for our core package, people can continue bringing core.scss into their project or use the new module version core.mod.scss. This does introduce duplication of partials, but since our styles are pretty established at this point, I’m not worried about maintaining it for the deprecation period

there are some similarities with where USWDS is at:

1. USWDS styles are quite established
2. minimal component growth on the roadmap

You may want to start socializing folks move over to dart sooner than later.

If folks want to stay in the Ruby ecosystem, I found https://www.npmjs.com/package/dart-sass-rails

You could also tell users of deprecated Sass implementations to pin their versions to avoid breaking changes if they don't want to change.

There's an interesting cross-compatible solution mentioned at sass/sass#2565 (comment). It's not perfect, since it would leave @use statements in the generated CSS for non-Dart SASS, but as mentioned in the comment, it shouldn't break anything to have in the output.

I tried playing with some ideas to detect if the current compiler is Dart, and while it does seem possible to detect, there's still no obvious way to bring in Dart's math methods, since conditional imports aren't supported.

@if function-exists("module-functions") {
  // Dart SASS
} @else {
  // Not Dart SASS
}

Alternatively, maybe a "polyfill" for division which uses only addition, subtraction, and multiplication?

@function divide($dividend, $divisor, $precision: 10, $depth: 0) {
  $result: $dividend * 0;
  @while $dividend - $divisor >= 0 {
    $result: $result + 1;
    $dividend: $dividend - $divisor;
  }

  @if $dividend > 0 and $depth < $precision {
    $result: $result + divide($dividend * 10, $divisor, $precision, $depth + 1) * .1;
  }

  @return $result;
}

This was originally superseded by #4314, but if USWDS v3 is aiming to target Sass modules, it would be a good idea to revisit the native Sass math function, as I would assume it's going to perform much better than the polyfilled version of #4314.

@mejiaj, will this be incorporated in #4539 ?

@aduth, yes we'll be using the native sass.math() in beta.

Closing this since we're using SASS modules in USWDS 3.

Thanks @maya for the contribution and nudge to get on this!