Numbers get rounded when using @arguments

[vkbansal]

I'm using the following code.

.transitions(...){
    @arg : ~`"@{arguments}".replace(/[\[\]]*/g, '')`;
    -webkit-transition: @arg;
       -moz-transition: @arg;
        -ms-transition: @arg;
         -o-transition: @arg;
            transition: @arg;
}

.transitions(opacity 0.3s ease-in 0.3s, max-height 0.6s linear, margin-bottom 0.4s linear;);

And it produces the following result.

-webkit-transition: opacity 0s ease-in 0s, max-height 1s linear, margin-bottom 0s linear;
-moz-transition: opacity 0s ease-in 0s, max-height 1s linear, margin-bottom 0s linear;
-ms-transition: opacity 0s ease-in 0s, max-height 1s linear, margin-bottom 0s linear;
-o-transition: opacity 0s ease-in 0s, max-height 1s linear, margin-bottom 0s linear;
transition: opacity 0s ease-in 0s, max-height 1s linear, margin-bottom 0s linear;

As you can see 0.3, 0.4 get rounded to 0 and 0.6 gets rounded to 1

[vkbansal]

The problem is with gulp-less not less. My bad.

[seven-phases-max]

Just in case it does look like Less issue, e.g. v.1.7.1:

.transitions(...) {
    @arg: ~`"@{arguments}".replace(/[\[\]]*/g, '')`;
    1: @arg;              // rounded to integers
    2: ~`"@{arguments}"`; // rounded to integers
    3: @arguments;        // OK
}

But I'm not reopeing this since you don't need inline javascript there since Less v1.3.2 as soon as you use ; as the args delimiter (see [3] above).

[seven-phases-max]

Oh, no, I guess I'll reopen this. It looks like it's a regression bug (introduced with #1814?) because it's compiled as expected with v1.6.x.
(@vkbansal but this does not cancel the recommendation to clean your code up of a legacy hacks).

[marekhrabe]

This also affects all mixins in LESS Hat. Are there any workarounds or is this a bug in core?

[vkbansal]

@seven-phases-max I got this idea from LESS Hat, which is heavily depended on such 'legacy hacks'. Its very useful. This is a mixin, I created for positioning of elements after having a look at LESS Hat.

[petrbrzek]

This commit caused the problem. Quick fix is to use the interpolation syntax ~"0.5".

[seven-phases-max]

@petrbrzek

Yes, most likely. Inline JavaScript stuff is not massively covered by the tests so we could just overlook the regression. I'll try submit a fix sooner (though it won't probably get into release soon since v1.7.1 has been just released).

[seven-phases-max]

@vkbansal

This is a mixin, I created for positioning of elements

Same w/o javascript (I only changed property delimiter to , so the whole thing can be more generic).

(offtopic: Btw. this is the use-case where #1857 would come handy, implementation could become more simple (with args-pattern-matching instead of endless length(@style) > n)).

[vkbansal]

@seven-phases-max
Thanks for the example. I did not know that it could be achieved that way. I was following the LESS Hat approach.

[lukeapage]

@seven-phases-max see commit, it was caused by weird code (that I don't think would have ever made sense) in the jsify function.

I'm planning a 1.7.2 release for this issue and one effecting alot of grunt users.

[seven-phases-max]

@lukeapage Thanks!

[vkbansal]

@lukeapage Thanks!

@seven-phases-max Thank you too

[bluetidepro]

I have this same bug, is it fixed?

[vkbansal]

@bluetidepro have a look at @lukeapage's reply above

I'm planning a 1.7.2 release for this issue and one effecting alot of grunt users.