Extend within (reference) imported files.

[donaldpipowitch]

Say I have three files:

// fileA.less
.test-a {
  color: red;
}

// fileB.less
@import (reference) "fileA";

.test-b {
  background-color: green;
  &:extend(.test-a all);
}

// fileC.less
@import (reference) "fileB";

.test-c {
  &:extend(.test-b all);
}

What I expect, if I compile fileC.less (comments only to aid the understanding):

// .test-a,
// .test-b,
.test-c {
  color: red;
}

// .test-b,
.test-c {
  background-color: green;
}

What I get:

.test-b,
.test-c {
  color: red;
}
.test-c {
  background-color: green;
}

.test-b leaks in!

[seven-phases-max]

.test-b leaks in!

This is just how extend works currently. It is questionabe if .test-b should appear in the output (i.e. ideally it may not output however there's also no reason why it must not), but the whole snippet looks more like "trying to use (reference) as a hack to achieve #1177".

[lukeapage]

I think its a bug, but would need to work out what's causing it to be sure.

[seven-phases-max]

Ah., sorry, my bad. I did miss that with the one level @import it actually supresses the output of the extended class (I was under impression that I have tried this as #1177 workaround before and it did not work... But aparently my test was somewhat wrong :)

[SomMeri]

I think that the expected output in the above should be:

.test-c {
  color: red;
}
.test-c {
  background-color: green; // changed from color: red;
}

[donaldpipowitch]

You're right. That is a typo in my example. I will fix this.

[bassjobsen]

as far as i understood, the problem also occurs without nesting:

@import (reference) "testextend.less";

with testextend.less contains:

.extendthis {
notvisible: notvisiblevalue;
}
.a:extend(.extendthis){}
.c {
notvisible: notvisiblevalue;
}

will be compiled into:

.a {
  notvisible: notvisiblevalue;
}

Where i expected no output at all. Tested with 1.6.3 and 1.7.0

[donaldpipowitch]

Any progress on this and the related issues?

[donaldpipowitch]

@lukeapage Any chance to get this fixed for version 2.0.0? This would be incredible useful if you distribute very modular files via npm or Bower.

[lukeapage]

Im not going to delay v2 till this is fixed... It might be easy to fix though..

[lukeapage]

I would create a test case, then debug extend visitor, look at where it creates the new selector and make sure its referenced field is only set to true if the extend is referenced (which it wont be if ibside a refrenced import).
but not entirely sure, its been a while sjnce working on those features.

[donaldpipowitch]

Thank you for the effort.

[bassjobsen]

i wonder if this issue can be fixed by using the following lines of code in parser/parser.js:

if(typeof elements[0].currentFileInfo.reference === "undefined"
|| elements[0].currentFileInfo.reference === false)
{
    extend = new(tree.Extend)(new(tree.Selector)(elements), option, index);
    if (extendList) { extendList.push(extend); } else { extendList = [ extend ]; }
}

The above than should replace the lines:

    extend = new(tree.Extend)(new(tree.Selector)(elements), option, index);
    if (extendList) { extendList.push(extend); } else { extendList = [ extend ]; }

[lukeapage]

No, because that would stop you extending the result of an extend through a
reference.

[bassjobsen]

Well, i see. Thanks.
It seems possible to fix this issue in the to-css-vistor.js inn the filter function:

                .filter(function(p) {
                    var i;
                    if (p[0].elements[0].combinator.value === ' ') {
                        p[0].elements[0].combinator = new(tree.Combinator)('');
                    }
                    for(i = 0; i < p.length; i++) {
                        if(
                        typeof p[i].elements[0].currentFileInfo.reference === "boolean" && 
                        p[i].elements[0].currentFileInfo.reference &&
                        ) return false;
                        if (p[i].getIsReferenced() && p[i].getIsOutput()) {
                            return true;
                        }
                    }
                    return false;
                });

But that left other issues with mixins in the referenced files un-fixed; mixins called from the main file (#1979) and mixins with nested selectors (#1968). Probably this rules should get the referenced state of the caller instead of that from the mixin.

[assadtony]

Any updates on this issue? :)

[SomMeri]

This should be fixed by #2729 .

[donaldpipowitch]

Just wow!

[SomMeri]

Re-opening, because it now compiles into

.test-c {
  background-color: green;
}

instead of

.test-c {
  color: red;
}

.test-c {
  background-color: green;
}

[matthew-dean]

Okay, if you get a fix for it, we can do a bugfix release soon.