added failing test for #49 #431
Conversation
|
my naive first attempt was to try and remove duplicate rules when rendering a ruleset but this causes other tests to fail since they depend on the output containing duplicated rules. however, when the css is parsed, only the last rule will be effective so this wouldn't change the effect of the resulting css. in case anybody wants to see that approach, this is the diff. if @cloudhead likes this, i'll make a pull request of it. otherwise, i'll still be looking for other ways to fix this issue. diff --git a/lib/less/tree/ruleset.js b/lib/less/tree/ruleset.js
index cc9a60a..3aee4ca 100644
--- a/lib/less/tree/ruleset.js
+++ b/lib/less/tree/ruleset.js
@@ -114,6 +114,7 @@ tree.Ruleset.prototype = {
rulesets = [], // node.Ruleset instances
paths = [], // Current selectors
selector, // The fully rendered selector
+ names = {}, // used to remove duplicate names in rulesets
rule;
if (! this.root) {
@@ -161,6 +162,11 @@ tree.Ruleset.prototype = {
return s.toCSS(env);
}).join('').trim();
}).join(env.compress ? ',' : (paths.length > 3 ? ',\n' : ', '));
+ // only keep the last occurence for rules with the same name
+ rules = rules.reverse().filter(function (rule) {
+ var name = rule.substr(0, rule.indexOf(':'));
+ return !(name in names) && (names[name] = 1);
+ }).reverse();
css.push(selector,
(env.compress ? '{' : ' {\n ') +
rules.join(env.compress ? '' : '\n ') +
|
- this maintains the behavior where all mixins that matched the call are applied - if the result of applying the mixins produces rules with the same name then the last rule with that name wins - an alternative approach would be to only apply the last mixin that matches the call
|
@cloudhead, there are alternative ways to approach this fix but this was the least different to how things work now. i'd be glad to take a different approach if you prefer. |
the following would be intentional and should be allowed:
.foo {
background: #fff;
background: rgba(255, 255, 255, 0.8);
}
|
Agree. This need merging. |
|
@jeremyricketts this is not the only open pull request that solves bugs that have existed for a long time. a number of people maintain their own forks of this project because of the lack of support for this library. if you have the opportunity to try an alternative library you should do it. unfortunately i need to maintain some projects that don't have the opportunity to move away from less right now so i have to keep trying to get pull requests applied. my current philosophy is "no less, no more" - i won't be using it on any new projects. i've learned a valuable lesson that a permissive license is only a small part of being open source. |
|
I tried a pull of your fork of less earlier and checked out the multi-mixin branch. Unfortunately it was using the older version of less and also wasn't compatible with the newer way of requiring modules. ie dropping require.paths. I've tried to copy what you did by using the I see also that the version of less that Dojo uses is old too, so I couldn't drop my .less files into the /themes/* as my own custom replacement of claro/soria etc. I'm assuming that the other projects that you were referring to is Dojo, and my question is, 1) Do you have plans to bring your fork upto date with the latest version of Less? 2) Will Dojo ship with a later version of less seeing as it doesn't support some of the more useful mixin properties at the moment. (ie using |
|
yes, dojo is one of the other projects i was referring to. the fork in the neonstalwart account is just for me to provide pull requests - i don't keep it up to date unless i need to open another pull request. if i recall correctly, the "usable" branch in my repo is the best one to try but i haven't touched it in a while. the fork that i use for work with my employer is at https://github.com/cello/less.js and it should be usable in some form but i also don't update it unless i need to. now that less 1.3 has just been released, i plan to update dojo to use that but dojo doesn't use a patched version of less so that won't help you. |
|
This won't work because we need the ability to specify multiple attributes with the same name.. |
|
@cloudhead did you look closely? it allows for multiple attributes with the same name - look at the tests. |
|
Ah I just looked at the diff. If we're comparing with values too though, may as well do it for everything? |
|
@cloudhead what do you mean? what needs to change? |
|
Ok, here's the fix: cb78933 |
|
@cloudhead i see - that does the same thing i was doing except i was avoiding calling i'll try to get around to opening a pull request with some more tests to cover this and another with the change to be able to run the tests from any dir. |
|
...and i see what you mean by do it for everything - not just mixins. |
change underscore dependency to lodash
test case to show problem described in #49