Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend from @import (reference) #1878

Closed
SomMeri opened this issue Feb 16, 2014 · 17 comments
Closed

Extend from @import (reference) #1878

SomMeri opened this issue Feb 16, 2014 · 17 comments
Assignees

Comments

@SomMeri
Copy link
Member

SomMeri commented Feb 16, 2014

Selectors from file imported as (reference) can extend rulesets in the main file. I think that nothing from reference imported file should appear in the main file, unless main file asks for it (either by extend or mixin).

The file import-as-reference-extend.less contains one extend:

.unusedAndReference:extend(.mainRuleset) {
    unused-and: reference;
}

and main.less imports it as reference:

@import (reference) "import/import-as-reference-extend.less";
.mainRuleset {
    main: ruleset;
}

It is compiled into:

.mainRuleset,
.unusedAndReference {
  main: ruleset;
}

Expected result:

.mainRuleset{
  main: ruleset;
}

Tested on windowns node.js less-1.6.3.js

@matthew-dean
Copy link
Member

Agreed. (reference) is implied to be passive until "activated" by another call. I would classify this as a bug.

@donaldpipowitch
Copy link

Looks like this bug: #1851

@SomMeri
Copy link
Member Author

SomMeri commented Feb 17, 2014

I think they are slightly different. In this case of referenced file extends something in main file. The other issue is a problem with chaining references, e.g. test-b probably appears in the output cause it extends yet another hidden selector.

@mark-casasoft
Copy link

I have this exact same issue. When I have a file which is importing bootstrap by reference and the file is empty, I would expect no output yet due to the 'extend' keyword, all the files which use such an extend keyword (mostly to extend with the clearfix class), gets output as well!

@casasoft
Copy link

Exactly same issue!

@chharvey
Copy link
Contributor

@markcsasar Similar to what's happening to me. It really screws with overridden properties.

LESS:

/* fileA.less */
.box-inline {
    display: inline;
    border: 1px solid black;
}
.box-inline-block {
    &:extend(.box-inline);
    display: inline-block;
    font-style: italic;
}
.box-block {
    &:extend(.box-inline-block);
    display: block;
    font-weight: bold;
}

/* fileB.less */
@import url('fileA.css');
@import (reference) url('fileA.less')
/* nothing here */

What I actually get for the CSS:

/* fileA.less */
.box-inline,
.box-inline-block,
.box-block {
    display: inline;
    border: 1px solid black;
}
.box-inline-block,
.box-block {
    display: inline-block;
    font-style: italic;
}
.box-block {
    display: block;
    font-weight: bold;
}

@import url('fileA.css');
/* fileB.less */
.box-inline-block,
.box-block {
    display: inline;
    border: 1px solid black;
}
.box-block {
    display: inline-block;
    font-style: italic;
}
/* nothing here */

Expected result for the CSS:

/* fileA.less */
.box-inline,
.box-inline-block,
.box-block {
    display: inline;
    border: 1px solid black;
}
.box-inline-block,
.box-block {
    display: inline-block;
    font-style: italic;
}
.box-block {
    display: block;
    font-weight: bold;
}

@import url('fileA.css');
/* fileB.less */
/* nothing here */

Now when I link fileB.css:

<html>
    <link rel="stylesheet" stylesheet="fileB.css"/>
    <div class="box-block">Hello, world.</div>
</html>

This is what div.box-block looks like:

display: inline; (fileA.css:5)
border: 1px solid black; (fileA.css:6)
display: inline-block; (fileA.css:10)
font-style: italic; (fileA.css:11)
display: block; (fileA.css:14)
font-weight: bold; (fileA.css:15)
display: inline; (fileB.css:5)
border: 1px solid black; (fileB.css:6)
display: inline-block; (fileB.css:9)
font-style: italic; (fileB.css:10)

And this is what div.box-block should look like:

display: inline; (fileA.css:5)
border: 1px solid black; (fileA.css:6)
display: inline-block; (fileA.css:10)
font-style: italic; (fileA.css:11)
display: block; (fileA.css:14)
font-weight: bold; (fileA.css:15)

@calvinjuarez
Copy link
Member

For the sake of discussion, I'd like to ask, what would we expect from mixins defined in the referenced file that extend classes also within the referenced file?

For example, given these LESS files, the I'd expect the output to look like that CSS there at the bottom. Any fix for this bug should preserve this behavior, IMO.

prototype.less

.prototype {
  proporties: here;
  .child {
    child-proporties: here;
  }
}
.extends-prototype() {
  &:extend(.prototype);
  & &-child { &:extend(.prototype .child); }
}

main.less

@import (reference) 'prototype.less';

.instance {
  .extends-prototype();
}

main.css

.instance {
  proporties: here;
}
.instance .instance-child {
  child-proporties: here;
}

@LordZardeck
Copy link

I'm having the same issues here. If I try to import bootstrap by reference and don't actually have any less styles, I still get output, even though technically I shouldn't. Using less v1.7.0 and node v0.10.25.

@JLLeitschuh
Copy link

1+ Even if there was a work around that would be great.

@hybopressthemes
Copy link

+1

I am facing same issue. Please make it a priority, its been 1+ years since it was first reported here.

As we use automation tools to generate css and also minify etc. So its passed onto users, and not only it adds extra bytes but also confuses users if they have a look at css files. (I know I can manually clean it up, but why should I, if I have already invested so much in automation).

Hopefully it gets solved soon, or at-least provide hack until you fix it in core..

@matthew-dean
Copy link
Member

I just ran into a variant of this bug, in which a class that extended another class ended up in the resulting CSS, even though BOTH classes were behind an @import (reference) call. Meaning, just the presence of an :extend seems to break the (reference) feature, and there's no way to "hide" the rulesets that use extend.

@alexkrauss
Copy link

We are running into this in a highly modular setup, with particularly bad consequences:

  • Many components. Each component foo has its own less file foo.less
  • Everything is packaged together in the end using webpack.
  • Most of these component styles import basic library material: @import (reference) '../base-styles'
  • The library material makes frequent use of extend
  • Thus we get large parts of the library duplicated, which leads to prohibitively large bundles even for just a few pages.

So, this is just to emphasize the importance of this issue :-).

@SomMeri SomMeri self-assigned this Oct 11, 2015
SomMeri pushed a commit to SomMeri/less-rhino.js that referenced this issue Nov 20, 2015
- refactored how import reference works
- refactored to-css-visitor (this is side product, it was getting
  complicated)
- fixes issues less#1851, less#1896, less#1878, less#2716, less#1968, less#2162 (same as less#1896)
@SomMeri
Copy link
Member Author

SomMeri commented Dec 7, 2015

This should be fixed by #2729 .

@SomMeri SomMeri closed this as completed Dec 7, 2015
@mohammed-softordi
Copy link

@SomMeri thanks you work, is this merge released? I am having the same problem with the latest release (2.5.1).

@seven-phases-max
Copy link
Member

@mohammed-softordi You can find if the changes were released by comparing the PR merge date (Nov 20, 2015 in this case) to the releases date in the Changelog (the latest release is 2.5.3 of 2015-09-25).

@SomMeri
Copy link
Member Author

SomMeri commented Jan 27, 2016

@mohammed-softordi No it was not released yet. That pull request was finished last December while last release was in September.

@mohammed-softordi
Copy link

@seven-phases-max @SomMeri thanks, it would be really great if you could release the fix but, no pressure :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

14 participants