Repository navigation
Multiple scoped imports via (reference) fail #3813
Description
To reproduce:
.foo {
@import (reference) "abc";
.one {
.two(); // defined in abc.less
}
}in another file
.bar {
@import (reference) "abc";
.three {
.two(); // defined in abc.less
}
}Current behavior:
The second use of .two() fails with "NameError: .two is undefined in ..."
Expected behavior:
Both references should work.
Environment information:
I don't think the env matters here, but...
lessversion: 3 and 4nodejsversion: 18operating system: Ubuntu 20.04
** Additional **
There is a workaround here by using:
@import (multiple, reference) "abc";
The right behavior seems to me to be that the second reference should work because:
- The first reference is scoped, and therefor abc.less is not actually getting included twice, in the sense that duplicate css is being produced.
- It's a reference, and doesn't generate duplicate code anyway. Why not make the default 'multiple' to avoid the issue I had?
- Treating references in the manner suggested here seems to be the more typical way that compilers treat libraries.
If a change isn't made to the code, it seems like it may be worthwhile to put this info into the documentation somewhere.
Activity
matthew-dean commentedon Oct 2, 2023
I don't disagree this is somewhat counter-intuitive, but it's consistent with the way that
@importis defined. In other words,@importwas defined first with a "single-call" kind of pattern, to avoid duplication. Thenmultiplewas added to signal duplication. Thenreferencewas added. (I could have the order of the last two flipped.)In the future, this will likely be made more clear with more intuitive behavior with separate at-rules for including qualified rules vs including variables / mixins. See: less/less-meta#39
Lfan-ke commentedon Jul 25, 2026
Still reproduces on current
master. In the meantime there is a workaround: add themultiplekeyword so the file is brought into each scope instead of being deduplicated:Both
.two()calls then resolve.The underlying cause looks like the same-file import dedup: the second
@import "abc"is treated as already-imported and skipped, so its mixins never land in the second scope. The check is inimport-manager.js(theimportManager.files[...]guard, unlessoptions.multiple). Whether a(reference)import - which only emits the parts that are actually used - should be exempt from that dedup is really the design question here.