[WIP] dart-sass compatibility tweaks

[atesgoral]

WHY are these changes introduced?

Sass is not going away any time soon (~6 mo). It might be still worth updating to dart-sass.

WHAT is this pull request doing?

Taking a stab at updating to dart-sass and fixing compatibility issues that pop up.

Ran automigration for division operators (to convert them to multiplication): npx sass-migrator division src/**/*.scss

The "compact" value for outputStyle is not supported by dart-sass. "expanded" is the default. So, just removed the option.

How to 🎩

🖥 Local development instructions
🗒 General tophatting guidelines
📄 Changelog guidelines

Copy-paste this code in playground/Playground.tsx:

import React from 'react';
import {Page} from '../src';

export function Playground() {
  return (
    <Page title="Playground">
      {/* Add the code you want to test in here */}
    </Page>
  );
}

🎩 checklist

• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility
• Updated the component's README.md with documentation changes
• Tophatted documentation changes in the style guide
• For visual design changes, ping @ sarahill to update the Polaris UI kit

[ghost]

👋 Thanks for opening your first pull request. A contributor should give feedback soon. If you haven’t already, please check out the contributing guidelines.

[BPScott]

Yay for preparing to move to dart-sass. However there are compatibility issues with putting dart-sass only code into the public API.

We'll either need to come up with some work arounds to support usage in both node-sass and dart-sass, or remove the problematic parts of the public API before moving to dart-sass

[BPScott]

This is going to be an issue.

Code in src/components all get compiled and shipped as css so we can author those files in whatever format we want, no problems there.
Code in src/styles (or more strictly, code in files imported from src/styles/_public-api.scss) however is the Polaris public sass API, and is used by consuming apps. This means that any code in these files needs to be understood by consuming apps. Introducing @use - dart-sass only syntax - here is a breaking change as it means that consumers will no longer be able to author app scss in node-sass. We create a hard dependency of:this version of polaris ships mixins with dart-sass specific syntax and thus can only be use in apps that compile their scss with dart-sass.

In order to not require a specific major version of polaris to be tied to a specific version of sewing-kit this either needs to be reworked, and either we remove these utilities from polaris (color() is considered not desired but its usage in consuming apps is pervasive which means it's hard to remove) before performing the migration to dart-sass or we come up with some way to support both node-sass and dart-sass.

On the up-side it's been agreed upon that having a sass API is not desired, and it causes more hassle than desired, however work to actually remove it is slow going.

[BPScott]

This looks like a straight up bug and we can remove this in a separate pr

[atesgoral]

#4308

[BPScott]

Another case where dart-sass only code is introduced to the public sass API

[nickpresta]

We will want to use sass.renderSync, which is apparently the faster of the two methods. I did a similar thing in here

[atesgoral]

@nickpresta Feel free to take this branch over as I had abandoned this effort a while ago...

[BPScott]

Gonna close this. It'll be easier to reopen in the future. Lots of these changes have superseded. See #4725 for thoughts on deprecation warnings.