Remove legacy colour palette

[querkmachine]

Part of removing compatibility mode.

Closes #2792.

Changes

Removing legacy colour palette

• Removes $legacy parameter from instances of govuk-colour in components.
• Removes separate legacy colour handling from Footer component and edit border-top style to account for removed variable.
• Removes $govuk-use-legacy-palette and $govuk-colours settings.
• Removes private $_govuk-colour-palette-legacy variable.
• Renames $_govuk-colour-palette-modern to $govuk-colours, making it public and overrideable as per the original $govuk-colours setting.
• Removes tests related to legacy colour palette.

Deprecations

We mistakenly did not deprecate the govuk-colour function's $legacy parameter at the same time as the related code in v4.4.0, so it's being deprecated in this release instead.

However, due to the removal of the other legacy colour palette code, it is non-operational and the parameter is only maintained to prevent compilation errors from outdated function references.

• Updates Sassdoc for govuk-colour to note the deprecation.
• Updates govuk-colour function to output a deprecation warning if the $legacy parameter is used.
• Adds a test to ensure that the deprecation warning is being output.

[colinrotherham]

❤️

[colinrotherham]

That was quick 🚀

I know we have #3575 in progress but will we follow up with the Review app changes?

Things like the ?legacy=true query handling:

app.use(middleware.legacy)

Plus all the href: "/" + legacyQuery Nunjucks wrangling etc

[querkmachine]

@colinrotherham I imagine that's all going to be handled as part of #2794

[owenatgov]

All looking good 👍🏻 A couple of comments:

• To clarify the above comment, @querkmachine is right and part of that work will be to scrub legacy testing from the review app et al.
• I'm a little nervous about the fact we're also removing the $legacy option from govuk-colour because we haven't explicitly deprecated it. This was an oversight on my part on in not deprecating it when I deprecated $govuk-use-legacy-palette. Practically speaking it doesn't do anything without the now removed setting but I'm worried we'll be breaking codebases for teams who may have it ingrained to do it as a best practice. I'm not gonna cling to this point. The functionality is fairly clearly tied to this removal and we attempt to be clear in our changelog that this is going away. Interested in thoughts on if this should stick around with a deprecation warning and be removed in v6 as a final layer of removal.

[querkmachine]

Good point that we never explicitly deprecated $legacy, I'm not sure how best to handle that.

We could keep accepting the parameter and add a deprecation message, but given it won't actually work anymore, it doesn't strike me as technically being a deprecation, it's just a removal with fewer error messages.

Though given we have deprecated the $govuk-use-legacy-palette setting, whether activated manually or programatically via one of the Template/Toolkit/Elements settings, I don't think there's any way someone actually using the legacy palette wouldn't have seen a deprecation warning in 4.6.0. We might be able to get away with it?

[owenatgov]

@querkmachine I've just found an example of it being used in govuk_publishing_components: https://github.com/alphagov/govuk_publishing_components/blob/99938773aef7a14e8f67c878f5ed0d9deddd09e0/app/assets/stylesheets/govuk_publishing_components/components/_layout-header.scss#L7 There are quite a few examples in gpc, I suspect from when they had to support legacy frameworks on some of their apps that consume this gem. 99% of govuk isn't using compatibility mode which is why I suspect this is primarily a best practice, however this will mean we have a scenario where teams will be using $legacy and may not have seen the warning. It feels to me like we have 2 options:

1. Keep $legacy as a possible parameter to block unexpected errors that doesn't do anything besides throw up a warning telling users that this doesn't do anything and we'll be formally removing it in v6.
2. Proceed with present course and get rid of it with a nod in our changelog.

I'm leaning towards 1 for the sake of code hygiene and us following a positive deprecation model, but I'm open to discussion.

[colinrotherham]

Good practice for a v4 patch release to mop up any missed deprecations?

[querkmachine]

I think a v4.6.x patch is probably a good shout. I can see the v4 releases still being used for a while, no matter how v5 development goes

• If the v5.0.0 release is entirely about restructuring and removals without any significant new features, and it's subsequently released quite soon, then we may have a lot of teams hold off on it and stick to v4.6.x until there's more reason to upgrade.
• If we do decide to incorporate bigger features into v5.0.0, then I can imagine development taking a while longer, in which circumstances more teams will have ended up on v4.6.x and see the new deprecations.

[owenatgov]

Adding a 2nd approval 🎨