Deps: Use sass-loader v13

[tyxla]

Proposed Changes

Consistently use sass-loader@13 instead of 3 different versions.

Why are these changes being made?

During the latest WordPress monorepo upgrade (#96470) I noticed this inconsistency and thought it might make sense to be fixed.

Testing Instructions

• Build should work well and all checks should be green.
• Do some smoke testing and verify things work well.

[github-actions]

Calypso Live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-133990

Jetpack Cloud live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-133990&env=jetpack

Automattic for Agencies live (direct link)

https://calypso.live?image=registry.a8c.com/calypso/app:build-133990&env=a8c-for-agencies

[matticbot]

This PR modifies the release build for the following Calypso Apps:

For info about this notification, see here: PCYsg-OT6-p2

• blaze-dashboard
• command-palette-wp-admin
• help-center
• newsletter
• notifications
• odyssey-stats
• whats-new
• wpcom-block-editor

To test WordPress.com changes, run install-plugin.sh $pluginSlug update/sass-loader-13 on your sandbox.

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[ciampo]

Looking at the CHANGELOG, the only 2 breaking changes possible affecting us may be:

• emit @warn at-rules as webpack warnings by default, if you want to revert behavior please use the warnRuleAsWarning option (fix!: emit @warning as webpack warning webpack-contrib/sass-loader#1054) (58ffb68)
• using ~ is deprecated and can be removed from your code (we recommend it), but we still support it for historical reasons.

Should we address / apply any refactors before updating?

[m1r0]

Should we address / apply any refactors before updating?

I'm on a dependency update rotation so I can take a look. Is that ok with you, @tyxla?

[tyxla]

@m1r0 definitely! I haven't had time to look into it today, so feel free to take over!

[m1r0]

emit @warn at-rules as webpack warnings by default, if you want to revert behavior please use the warnRuleAsWarning option (webpack-contrib/sass-loader#1054) (58ffb68)

I was not able to get warnRuleAsWarning to work. I've tried adding the property to the sass-loader options but there's no difference if it's true or false - the warnings are not displayed in the console when running yarn start. On trunk, when using @warn, I can see the warnings in the console. Any ideas? 🤔

Trunk:

Now:

[tyxla]

@m1r0 can you please provide a diff to demonstrate what you tried? Thanks!

[m1r0]

Sure, here you go:

diff --git a/client/landing/stepper/declarative-flow/internals/global.scss b/client/landing/stepper/declarative-flow/internals/global.scss
index cde9714f3ef..f31e8304e65 100644
--- a/client/landing/stepper/declarative-flow/internals/global.scss
+++ b/client/landing/stepper/declarative-flow/internals/global.scss
@@ -12,6 +12,8 @@
  */
 @import "calypso/blocks/import/style/base";

+@warn "THIS IS A TEST WARNING";
+
 /**
  * General onboarding styling
  */
diff --git a/packages/calypso-build/webpack/sass.js b/packages/calypso-build/webpack/sass.js
index 09c12a634e5..95e501938fe 100644
--- a/packages/calypso-build/webpack/sass.js
+++ b/packages/calypso-build/webpack/sass.js
@@ -36,6 +36,7 @@ module.exports.loader = ( { includePaths, prelude, postCssOptions } ) => ( {
 		{
 			loader: require.resolve( 'sass-loader' ),
 			options: {
+				warnRuleAsWarning: true,
 				additionalData: prelude,
 				sassOptions: {
 					includePaths,

Note that warnRuleAsWarning defaults to false on v13.