Local Variable Scoping in Import Files

Thanks for the project, and taking time to read this request. I enjoy LESS immensely.

I’m running into a critical issue with variable scoping that’s preventing me from using @import to include multiple components in the same project.

Test Case

The actual implementation is a bit different, but it can be boiled down to a simple test case.

Consider a master file for outputting a concatenated release of components that imports several different components.

/* project.less */
@import "button.less";
@import "header.less";

And two components

/* button.less */
@component: 'button';
.debug {
  component: @component;
}

/* header.less */
@component: 'header';
.debug {
  component: @component;
}

---

The expected output is

.debug {
  component: 'button';
}
.debug {
  component: 'header';
}

But the actual output is

.debug {
  component: 'header';
}
.debug {
  component: 'header';
}

I’ve added a test case in zip format here

Rationale

I’m working on an open source component framework. Each component may include variable names that may be used in other components, but should be scoped to each component so that they do not conflict.

Variable overlap is inevitable with distributed component design since individual authors cannot be aware of the variables used in other components.

Currently the only way I can make my library work is to sandbox each component by compiling them separately, and informing developers that they cannot directly import components from my library in their less files.

For more details on the specific implementation that I’m running into trouble with you can see this overview, or peruse how a component loads a theme

[seven-phases-max]

@import (scoped) "package";

we already have that:

& {@import "package";}

It’s actually even better to move the & {} part into the “package” file itself if the isolated scope is its initial requirement.

P.S. Aside from above, the problem of @import (scoped) "package"; is the same as I pointed somewere around there - we should not throw a responsibility of providing a required library environment at the library user, it should be in hands of the library author (thus if we need something like this it should be inside “package” not out of it… and while (reference) has its reasonable excuse for being the way it is (simply because it’s primarily designed to be used with external non-modifiable CSS libraries), (scoped) would have no).

[matthew-dean]

LESS variables behave like CSS properties: the latest definition in a scope “wins”.

You can address this in your example by surrounding imports in a mixin scope.

.import-header() {
    @import "header";
}
.import-button() {
    @import "button";
}
.import-header();
.import-button();