@1.49.9 Skipped not serializable cache item 'Compilation/modules

[HarshitSrivastava007]

Hi, currently getting below error with my production build compilation, Can someone suggest me to handle this?

Failed to compile.

   SassError: 2 arguments required, but only 1 was passed.
     ╷
   5 │     margin-bottom: rem(16px);
     │                    ^^^^^^^^^
     ╵
     node_modules/bootstrap/scss/mixins/_breakpoints.scss 75:7  media-breakpoint-down()

   SassError: expected "+", "-", "*", "/", ",", or ")".
      ╷
   78 │       padding: rem(6px 10px);
      │                        ^
      ╵
    
   SassError: 2 arguments required, but only 1 was passed.
       ╷
   113 │   font-size: rem(14px);
       │              ^^^^^^^^^
       ╵
   
   Import trace for requested module:

   SassError: expected "+", "-", "*", "/", ",", or ")".
      ╷
   73 │         padding: rem(8px 12px);
      │                          ^
      ╵
   
   Import trace for requested module:

   SassError: 2 arguments required, but only 1 was passed.
       ╷
   500 │       font-size: rem(15px);
       │                  ^^^^^^^^^
       ╵
   
   > Build failed because of webpack errors

[ntkme]

Duplicate of #2059. See #2059 (comment)

[connorskees]

Perhaps this change should be pushed back to a later release, and a deprecation warning be emitted instead? Disallowing function names like pow, rem, and sin seems quite disruptive, even if in the pursuit of CSS compatibility.

Otherwise, it would likely be helpful to add a warning if a user tries to either create a function with one of the newly reserved names or if a user tries to call one of these newly reserved functions while a user-defined function of the same name is in scope.

[amxmln]

I just ran into this as well and it took me as a surprise as I would consider this a breaking change.

Why are these new functions not functions like linear-gradient which can be overridden? 🤔

[connorskees]

Why are these new functions not functions like linear-gradient which can be overridden

Sass performs simplification of these sorts of functions, so they're type-checked to what the browser expects and have special behavior when possible. See an example of this here (note this repl doesn't yet support these new functions).

[Goodwine]

Perhaps this change should be pushed back to a later release, and a deprecation warning be emitted instead? Disallowing function names like pow, rem, and sin seems quite disruptive, even if in the pursuit of CSS compatibility.

I agree, this potential issue wasn't caught during the proposal nor implementation. It's a lesson to be learned for an issue that I think will reappear for the Color Level 4, New Color Spaces proposal. (for example, the new color() function).

Natalie is currently out, we're waiting for her return before any further releases :)

Personally (and this is not authoritative) I agree it should have been pushed back with a deprecation warning period, or rolledback into 1.65.2 immediately. Now I feel it is "too late" and reverting would break those who made changes in response to this version which has been out for almost a week, so reverting is more difficult. I imagine something in between like "if there is a calc function available as a function without a namespace, don't parse as calculation and evaluate as function and print a warning". Not sure if that's the path we'll take.

I just ran into this as well and it took me as a surprise as I would consider this a breaking change.

https://sass-lang.com/documentation/breaking-changes/calc-functions/

why are these new functions not functions like linear-gradient which can be overridden?

Functions like linear-gradient are not processed nor validated by Sass. They are "unknown" to Sass, and these "unknown" functions are emitted as-is (the arguments are still evaluated and resolved tho). You can even implement your own @function linear-gradient() to do something completely different.

Before the breaking change, functions like rem() or pow() were also not being parsed any differently, we just had global functions available for them. But now, all of these functions are being parsed as calculations with new validations and everything. This was already the case for min() and max().

[Goodwine]

FWIW, looking for something else for an unrelated issue, I stumbled upon this relevant bug report for the same problem with min/max 🤔

sass/sass#3142

[amxmln]

I just ran into this as well and it took me as a surprise as I would consider this a breaking change.

https://sass-lang.com/documentation/breaking-changes/calc-functions/

For some reason I thought dart-sass was following SemVer, so I hadn’t checked, my bad.

Thanks for all the explanations, I can understand what happened. Renaming the function and retraining some muscle memory is probably the simplest solution, although I do feel like a bunch of people were caught quite off-guard by this.

[nex3]

I've reopened sass/sass#3504 to track this.