fix(styles): add error handling for rem & em sass functions

[jendowns]

Related to #4926 & #4927

I think it would be a good idea to add a little bit of error handling to the carbon--rem/carbon--em functions (and their deprecated versions too).

Since these functions all require pixel values to output valid CSS, it would be nice to notify developers directly from these functions when a non-pixel value is received. (Without pixel values, the functions return invalid output -- see this CodePen for examples: https://codepen.io/jendowns/pen/PowpyQJ)

• Info on Sass's @warn rule: https://sass-lang.com/documentation/at-rules/warn
• CSS Tricks article on advanced type checking in Sass: https://css-tricks.com/snippets/sass/advanced-type-checking/

Changelog

New

• add @error @warn check to carbon--rem/rem and carbon--em/em functions

[netlify]

Deploy preview for carbon-elements ready!

Built with commit e8cba9f

https://deploy-preview-4931--carbon-elements.netlify.com

[netlify]

Deploy preview for carbon-elements ready!

Built with commit 859a3ed

https://deploy-preview-4931--carbon-elements.netlify.com

[joshblack]

What would you think of the following warning format:

Expected argument $px to be of type `px`, instead received: `#{unit($px)}`

[netlify]

Deploy preview for carbon-components-react ready!

Built with commit 859a3ed

https://deploy-preview-4931--carbon-components-react.netlify.com

[joshblack]

@jendowns also, would adding @error here be considered a breaking change? Would it be better to use @warn so the sass build doesn't fail? Also would understand if we want it to fail in this case, but curious if people would consider it a breaking change as a result

[netlify]

Deploy preview for the-carbon-components ready!

Built with commit 859a3ed

https://deploy-preview-4931--the-carbon-components.netlify.com

[jendowns]

Thanks @joshblack! Just made the changes you suggested. Personally I prefer @error because I think failing, in this case, would help people find & address invalid values faster. BUT I can totally see how that would be breaking / disruptive so @warn seems like a safe way to go, just in case.

[joshblack]

@jendowns agreed that @error is preferred here, for sure. Would we want to leave a comment like:

// TODO: update to @error in v11

Above the @warn blocks? That way we can keep track of this for our next change. We could also comment on this change over in #4358 as well!

[jendowns]

Thanks @joshblack - I like that idea! I just pushed a commit with those comments added. I'll also add a comment to the issue you linked to, for v11 changes (unless you wanted to do that?)

[asudoh]

LGTM 👍 - Thanks @jendowns!