Upgrade Sass to 1.80.6 (and fix as many deprecations as possible)

[frankieroberto]

This upgrades Sass from 1.77.6 to 1.80.6.

The new version introduces a lot more deprecation warnings ahead of Sass 2.0.0 – so I’ve tried to fix as many as possible.

A lot of the warnings are from the vendored Sass-mq however. I've not touched that at all as it feels a bit icky to edit a vendor file (although it has had some code style tweaks over the years).

The GOV.UK Design System team are considering removing the sass-mq dependency altogether. However there was a 6.0.0 release of it last week which should resolve the deprecations.

The other remaining deprecation warnings are about use of @import - however moving away from is bigger job (changing every instance of @import to @use and namespacing all the imported functions).

Checklist

• Tested against our testing policy (Resolution, Browser & Accessibility)
• Follows our coding standards and style guide
• CHANGELOG entry

[paulrobertlloyd]

The other remaining deprecation warnings are about use of @import - however moving away from is bigger job (changing every instance of @import to @use and namespacing all the imported functions).

From the Sass docs:

You can even load a module without a namespace by writing @use "<url>" as *.

In my limited experience trying to move over to using @use, this means you can do the following:

- @import 'core.scss'
+ @use 'core.scss' as *

This then means you don’t need to use namespaced variables. However, the Sass documentation goes on to say:

We recommend you only do this for stylesheets written by you, though; otherwise, they may introduce new members that cause name conflicts!

Which is to say this may be a short term fix, but longer term, a breaking change could introduce an nhsuk namespace for all mixins, functions and variables owned by nhsuk-frontend.

[frankieroberto]

@paulrobertlloyd ooh nice, I hadn’t spotted that. It certainly could be a short-term option, and then we could gradually switch to namespaces, starting with the most-reused functions and mixins and so on?

[paulrobertlloyd]

Trying to resolve these deprecation warnings in my prototype, one thing with the above approach (@use "<url>" as *) is that it seemingly causes conflicts if 2 SCSS files export a variable, mixin or function with the same name. As this project shares some names with GOV.UK Frontend, I suspect there’d be clashes if you were to import anything from GOV.UK Frontend.

This module system seems nice ’un all, but get the feeling it’s an all or nothing kinda of affair. 😕 Definitely warrants more investigation.