mixins/variables from imports unavailable in other imports

[mlebarron]

util.less @white: #FFF; .zeropad {padding: 0;}

code.less img { .zeropad; }

base.less @import 'util.less'; @import 'code.less';

result: ! Name Error: * is undefined. ! Name Error: * is undefined.

put img { .zeropad; } in base.less instead of in code.less and it works fine

change code.less to a { color: @white; }

result: ! Name Error: @white is undefined.

[cloudhead]

That's because @import doesn't really work like an include, but more like an independent module/mixin, avoiding name conflicts with other modules.

So to use .zeropad in code.less, you would have to import util.less in code.less.

This might change in the future, if people are too confused with the behavior.. we'll see. Or I might add an @include directive.

[daz4126]

• 1 for this functionality

I think that when you are trying to create standard libraries/frameworks this comes in handy.

The usage i envisage is that you'd have one file that held all your colour definitions and others (your framework files) that contained other styles (eg grids,resets,widgets etc)

Then you would have one master.less file that imported/included ALL of the other less files and then set specific styles for the particular site you are working on.

That would mean all you would need to do is set your colours in one file, then put everything together in the other file. The framework files shouldn't be touched - just left to make their specific styles available to main.less

The proposed functionality would allow the framework files to reference the colours set in the colour file.

I hope that makes sense,

DAZ

[cloudhead]

that's how it currently works though..

[cloudhead]

lib.less @color1: #ff871a; @color2: #dd1100;

main.less

@import "lib";
a { color: @color1; }

output: a { color: #ff871a; }

What I was saying is imports don't bleed into other imports.

[mlebarron]

right... but they SHOULD be available to other imports. Especially when in the docs scope is referred to as similar to programming languages, and imports work as expected.

if, as in my example, I've already defined @white as #FFF in my util file, and util is included in the parent file of code, then @white should be available in code. otherwise every file I have is going to be a big mess of imports at the top.

Plus, and this is the huge problem I have with how this works, without silent classes or having imports available to all other files, everytime I import util.less, I get yet another .zeropad class output to my final css file.

[timkelty]

+1, exactly what I was looking for!

[kennethkufluk]

Ok, so if my global css file is something like this: @colour1: #F00; @colour2: #0F0; @colour3: #00F; @import "inc_rules.src.css"; @import "inc_rules2.src.css";

Then the imported files will not be able to use the colours I've declared?

And I have to specifically import a library of colours into each include file.

Seems wrong. +1 on this issue.

[kinghuang]

I also have this problem. I'm unable to migrate from Shaun Inman's CSS-Cacheer because variables aren't available to imported files. I have stylesheets set up like @kennethkufluk's example, so that variations can be made from a common set of rules. There doesn't seem to be a way to do this with less.

[muszek]

I strongly agree with all the people which request vars/mixins to be available in imported files. Or just create an @include which would work as we want it to and leave @import as it is... .

[memiux]

Yeah, the @include directive would be awesome

[smathis]

+1 on @include.

I'm having a really hard time using @import as is.

[alanhogan]

+1 on @include or modifying the behavior

[lukaszklis]

+1 on @include

I hope that this bug is going to be resolved soon, for now I had to use SASS on my current project which I don't really like at all...

[muszek]

klisiu: use less.js ( http://github.com/cloudhead/less.js ). it's a "new LESS" and @include behaves as you'd want it to.

[lukaszklis]

@muszek: thx a lot.

[gerrit]

any chance this functionality will be backported to the “classic” less?

[alanhogan]

Gerrit, consider Sass. It's more stable, reliable, flexible, and hey, it works from the command line. It even includes a tool to convert Less to Sass.

[jkpubsrc]

Just to give you an insight into how important that is.

I knew about less for many many years. But I had no need to use it as I did not do web design, so I did not use less. Until now. Now I required to design a CSS file (in a structured way) myself. I experimented with SASS/SCSS - but did decide against it as less currently has one 'killer' feature: Instead of having styles always precompiled less provides a script that does that on the fly. And this is excellent during design/development where you would do lot's of changes if you start building a good web design from scratch.

That was three days ago. Now: I wanted to structure my styles even more. Having a good structure is essential as otherwise things tend to no longer be manageable/maintainable in the long run. Styles are no exception. I therefore checked if there would be something such as an include statement. And there is. So the very first thing to work with include now was to move mixins into such an include file.

And things failed immediately: As I learned from this discussion mixins are not exported by an included file. (The documentation does not say anything about this!)

Let me try to be very precise as I'm not a native English speaker: The exact reason why I intended to use includes was to move mixins to an additional file as a) my mixins are reusable and b) they unnecessary fill up the main less file. I'd even go so far to say that moving mixins to an include file is the reason for having include files. It is a major aspect for having such an "include" file.

So I'd say: Being able to import mixins is not a nice-to-have-feature. I'd consider it as a mandatory requirement for designing an "include" feature for less in the first place. Mixins are a very convenient feature to get to small (and therefore well manageable) style sheet files. It's therefore essential that there is some mechanism how to include them into other files if you want to design style sheets in a reusable and modular way. I therefore recommend either to extend the include command regarding mixins or provide an additional way how to include mixins.

See: https://github.com/less/less.js/issues/3580

[jkpubsrc]

Maybe it would be adequate to assign a label such as "feature request"?