You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
4.2 breaking change: custom $grid-breakpoints that are smaller than default ones give errors #27927
WARNING: Invalid value for $grid-breakpoints: This map must be in ascending order, but key 'xxs' has value 0 which isn't greater than 1200px, the value of the previous key 'xl' !
WARNING: First breakpoint in `$grid-breakpoints` must start at 0, but starts at 480px.
WARNING: Invalid value for $container-max-widths: This map must be in ascending order, but key 'xs' has value 500px which isn't greater than 1140px, the value of the previous key 'xl' !
Reacted by Monili Nicolò, upsilon, Tonio, Roman Pokrovskij, KUDRIAVTSEV ANDREW, Constantin Cechina and Qihuan Piao
changed the title [-]4.2 broke building custom $grid-breakpoints that are smaller than default ones[/-][+]4.2 breaking change: custom $grid-breakpoints that are smaller than default ones give errors[/+]on Dec 27, 2018
The def of map-merge() specifies that the order of $map1 will have precedence while $map2 will override values.
/** * Merges two maps together into a new map. Keys in `$map2` will take * precedence over keys in `$map1`. * * This is the best way to add new values to a map. * * All keys in the returned map that also appear in `$map1` will have the * same order as in `$map1`. New keys from `$map2` will be placed at the end * of the map. * * Like all map functions, `map-merge()` returns a new map rather than * modifying its arguments in place. * * @example * map-merge(("foo": 1), ("bar": 2)) => ("foo": 1, "bar": 2) * map-merge(("foo": 1, "bar": 2), ("bar": 3)) => ("foo": 1, "bar": 3) * @overload map_merge($map1, $map2) * @param $map1 [Sass::Script::Value::Map] * @param $map2 [Sass::Script::Value::Map] * @return [Sass::Script::Value::Map] * @raise [ArgumentError] if either parameter is not a map */
@functionmap_merge($map1,$map2){/* stub */}
Since, unlike the other maps that are merged, the order is important, $map2 should have precedence.
To achieve this I think the double application of map-merge() should take care of it:
I have the same problem, i'm trying to compile with https://github.com/leafo/scssphp
Before the version 4.2 everything was ok, now i have the same mistakes as you.
The def of map-merge() specifies that the order of $map1 will have precedence while $map2 will override values.
/** * Merges two maps together into a new map. Keys in `$map2` will take * precedence over keys in `$map1`. * * This is the best way to add new values to a map. * * All keys in the returned map that also appear in `$map1` will have the * same order as in `$map1`. New keys from `$map2` will be placed at the end * of the map. * * Like all map functions, `map-merge()` returns a new map rather than * modifying its arguments in place. * * @example * map-merge(("foo": 1), ("bar": 2)) => ("foo": 1, "bar": 2) * map-merge(("foo": 1, "bar": 2), ("bar": 3)) => ("foo": 1, "bar": 3) * @overload map_merge($map1, $map2) * @param $map1 [Sass::Script::Value::Map] * @param $map2 [Sass::Script::Value::Map] * @return [Sass::Script::Value::Map] * @raise [ArgumentError] if either parameter is not a map */
@functionmap_merge($map1,$map2){/* stub */}
Since, unlike the other maps that are merged, the order is important, $map2 should have precedence.
To achieve this I think the double application of map-merge() should take care of it:
Nah, I solved it by changing the dep from ^4.1.0 to ~4.1.0 so it works in the build pipeline.
Easier than forking it for now.
Although, that code does fix it locally. It also needs to be done for the $container-max-widths as well:
I think we need to ditch these built-in map-merges for regular Sass maps. It now feels over-engineered, and perhaps poorly documented for how folks can customize things.
With the usage of map-merge everywhere, we have the ability to easily add key-value pairs, but not to remove them. There's no option in Sass to do this, but you can replace a value or add new ones (with map-merge). This is an issue because if you want fewer key-value pairs in a Sass map, you'll see errors like those of #27927 (comment).
So, what if we remove all map-merge in our variables?
Let's consider an example where we look at our $grid-breakpoints.
WARNING: Invalid value for $grid-breakpoints: This map must be in ascending order, but key 'xxs' has value 0px which isn't greater than 1200px, the value of the previous key 'xl' !
WARNING: First breakpoint in $grid-breakpoints must start at 0, but starts at 360px.
WARNING: Invalid value for $container-max-widths: This map must be in ascending order, but key 'xxs' has value 0px which isn't greater than 1140px, the value of the previous key 'xl' !
@Bek81
Those weren't instructions, he was giving an example of how sass maps could work and how they could potentially work in the core _variables.scss file. Simply revert to 4.1 until it's resolved as there's no fix without modifying _variables.scss.
There's also no use in using the merge-map in your own definitions of the variables. The last example @bdo gave would have to have the extra xxs and xxl variables in like $breakpoints-before / $breakpoints-after which is way overly complicated.
The example I provided makes overriding the breakpoints nearly the same as 4.1, but still has the issue of not being able to remove breakpoints. Reverting to the way it was done in 4.1 without merge-map seems like it might be the best solution. The update provides no benefit other than being able to override a single break point or add one larger, most other cases you'd need to override each breakpoint manually anyway.
the _assert_ascending function will throw the following warning:
Invalid value for $grid-breakpoints: This map must be in ascending order, but key 'ss' has value 320px which isn't greater than 1200px, the value of the previous key 'xl' !
scss/_functions.scss 18:7 _assert-ascending()
Adding @debug $key; @debug $num; you can easily see what's going on.
The ss value I've added in my custom.scss goes to end of the map so this function.
when compares $prev-num >= $num (1200px >= 320px) -> warning message
Note that this is just a warning so the CSS gets compiled.
Thanks!
If you really want to avoid this warning message you can (temporary and hacky fix) comment this line: @include _assert-ascending($grid-breakpoints, "$grid-breakpoints");
_variables.scss lines 201 and 221
Activity
[-]4.2 broke building custom $grid-breakpoints that are smaller than default ones[/-][+]4.2 breaking change: custom $grid-breakpoints that are smaller than default ones give errors[/+]phazei commentedon Dec 27, 2018
The def of map-merge() specifies that the order of
$map1will have precedence while$map2will override values.Since, unlike the other maps that are merged, the order is important,
$map2should have precedence.To achieve this I think the double application of map-merge() should take care of it:
Unless there's some other sass function that could handle this, I'm not sure of any better way.
phazei commentedon Dec 27, 2018
Additionally the docs give a specific use example:
which is no longer true since by just defining fewer breakpoints, the default ones will be added back in on merge.
nicolomonili commentedon Dec 28, 2018
I have the same problem, i'm trying to compile with https://github.com/leafo/scssphp
Before the version 4.2 everything was ok, now i have the same mistakes as you.
nicolomonili commentedon Dec 28, 2018
Have you solved in this way for now?
Upgraded NPM dependencies
phazei commentedon Dec 29, 2018
Nah, I solved it by changing the dep from
^4.1.0to~4.1.0so it works in the build pipeline.Easier than forking it for now.
Although, that code does fix it locally. It also needs to be done for the $container-max-widths as well:
XhmikosR commentedon Dec 29, 2018
/CC @MartijnCuppens
mdo commentedon Dec 30, 2018
I think we need to ditch these built-in
map-merges for regular Sass maps. It now feels over-engineered, and perhaps poorly documented for how folks can customize things.With the usage of
map-mergeeverywhere, we have the ability to easily add key-value pairs, but not to remove them. There's no option in Sass to do this, but you can replace a value or add new ones (withmap-merge). This is an issue because if you want fewer key-value pairs in a Sass map, you'll see errors like those of #27927 (comment).So, what if we remove all
map-mergein our variables?Let's consider an example where we look at our
$grid-breakpoints.To replace all of the values, we redefine the keys' values:
To replace individual key-value pairs, we use
map-merge:To add additional values, we also use
map-merge:To do a bit of everything, we can use replace the default values and use multiple
map-merges:You can see all of this in this Sassmeister gist.
Bek81 commentedon Jan 2, 2019
Hi @mdo
following your instructions, we are trying this way:
but these are the results:
Can you help us, please? Thanks a lot.
Benedetto
phazei commentedon Jan 2, 2019
@Bek81
Those weren't instructions, he was giving an example of how sass maps could work and how they could potentially work in the core _variables.scss file. Simply revert to 4.1 until it's resolved as there's no fix without modifying _variables.scss.
There's also no use in using the merge-map in your own definitions of the variables. The last example @bdo gave would have to have the extra xxs and xxl variables in like $breakpoints-before / $breakpoints-after which is way overly complicated.
The example I provided makes overriding the breakpoints nearly the same as 4.1, but still has the issue of not being able to remove breakpoints. Reverting to the way it was done in 4.1 without merge-map seems like it might be the best solution. The update provides no benefit other than being able to override a single break point or add one larger, most other cases you'd need to override each breakpoint manually anyway.
JulienCabanes commentedon Jan 4, 2019
It's also possible to sort maps after merge, I tried with this gist and it worked without changing anything else : https://gist.github.com/Jakobud/a0ac11e80a1de453cd86f0d3fc0a1410#gistcomment-2327765
ianks commentedon Jan 9, 2019
This is preventing us from upgrading to 4.2
carlosmauri commentedon Jan 10, 2019
Hi there,
what's the status of this "warning" issue?
I would suggest to just revert the new $grid-breakpoints declaration to what it was before, on the 4.1 version:
the new approach uses:
so when you try to update the variable using your custom.scss like this:
the _assert_ascending function will throw the following warning:
Adding @debug $key; @debug $num; you can easily see what's going on.
The ss value I've added in my custom.scss goes to end of the map so this function.
when compares $prev-num >= $num (1200px >= 320px) -> warning message
Note that this is just a warning so the CSS gets compiled.
Thanks!
If you really want to avoid this warning message you can (temporary and hacky fix) comment this line:
@include _assert-ascending($grid-breakpoints, "$grid-breakpoints");_variables.scss lines 201 and 221
unrevised6419 commentedon Jan 16, 2019
#25392