Avoid dart-sass deprecation warnings

[BPScott]

I've been starting to think about leveraging dart-sass. I've updated loom-plugin-build-extended to use dart-sass for package builds, and when attempting to use that in global-nav compiled output was as expected however it spammed the console with a bajillion deprecation notices regarding "use math.div instead of /" because using / to divide is deprecated in dart-sass.

Obviously this is a terrible user experience. It should be possible to use the public api with dart-sass without ruining console with incessant noise.

The gotcha comes here because polaris will need to support usage in consumers that use either node-sass or dart-sass.

Per my comments on #4298, fixes (as provided by the sass migrator) fall into one of two buckets:

• A fix that compiles in both node-sass or dart-sass. Such as changing $x: 8 / 2; into $x: 8 * 0.5
• A fix that keeps quiets dart-sass but is a compilation error in node-sass Such as changing $x: 8 / $var; into math.div(8, $var)

It should be easily possible to apply the fixes that compile in both straight onto main. But that leaves the other set.

Fortunately in the public-api the only cases where uncompilable fixes occur is in px(), rem(), em() and color-multiply() all of which are slated for removal in v9.

Options for that:

• Do nothing, wait till v9 is released and deprecations go away (though there is no promise of new, different deprecate behavior creeping in later until at some point in the far future we drop support for consumers using node-sass)
• After creating the build/styles folder, create a second build/styles-dart folder that contains the contents of src/styles, except ran through the sass migrator) - thus converting deprecated behaviour.

[BPScott]

Command to see what files would throw deprecation warnings: npx sass-migrator division 'src/**/*.scss' --migrate-deps --load-path=. --dry-run

At time of writing, running this against the v9 branch shows the following files:

• src/styles/shared/_breakpoints.scss. The one problem in our public API. Unfortunately its usage in consuming apps is pervasive. This isn't fixable till we rework how breakpoints are handled.
• src/components/ColorPicker/ColorPicker.scss. This is a false positive - the slash is used to separate values, it's not an instance of division.
• src/components/DatePicker/DatePicker.scss
• src/components/Layout/Layout.scss
• src/components/VideoThumbnail/VideoThumbnail.scss

[BPScott]

Once the complete removal of the public sass api is done in #4980 and v9 is released there shall be no more public sass api, and thus we won't need to worry about writing mixins/functions that work regardless of if a consumer is using node-sass or dart-sass because we won't have any more consumers.

At that point we're free to either continue to use node-sass, or migrate dart-sass (by changing the compiler, and performing any migrations) at leisure.

[BPScott]

Closing this. V9, which removes the public sass api, has shipped. No public sass api means no deprecation warnings when consumers try to use the public api.

At some point it'd be nice to migrate the polaris-react codebase to use dart-sass, but that work is now unblocked and can be done whenever with out affecting any consumers of the package.