-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
[Feature] Namespaced values #3242
[Feature] Namespaced values #3242
Conversation
- Simplify mathOn switch
# Conflicts: # package.json
# Conflicts: # dist/less.min.js # package.json
# Conflicts: # dist/less.js # dist/less.min.js # package.json
Note, this PR doesn't introduce breaking changes discussed in less/less-meta#12 - namely, it doesn't stop mixins from dumping vars into the caller scope. My thinking is we could introduce this feature, and document the deprecation of mixins leaking variables into scope. Then whenever that feature is removed (4.0?), there will hopefully be enough lead time and documentation to make the switch easy. |
I updated this PR to include setting mixins to variable calls / variable call lookups, see the added tests and error cases. .foo {
@theme: #ns.theme(dark);
color: @theme[color];
} |
So just now (after I should already be in bed), I realized you still COULD do some pretty amazing aliasing because of the nature and current behavior of mixins. I added two aliasing examples to tests to demonstrate this. Prepare to be like... So, with this PR, say you had this library file we'll call // better-bootstrap.less
#library {
.mixin(@a) when (@a = 1) {
@a: 20px;
}
.core() {
.colors() {
primary: blue;
foreground: white;
}
}
.buttons() {
.colors() {} // etc
}
} Okay, now we're gonna override some values in our overrides file. // overrides.less
#library {
.core() {
.colors() {
primary: rebeccapurple;
}
}
} Now let's import both and see some maaaaaaagic 🌈 // main.less
@import "better-bootstrap";
@import "overrides";
// Let's alias a call to #library.mixin, because why the f not
.alias() {
#library.mixin(1);
}
.foo {
.colors() { #library.core.colors; } // alias
width: .alias[@a];
background: .colors[primary];
color: .colors[foreground];
} So NOW, you would get this output: .foo {
width: 20px;
background: rebeccapurple;
color: white;
} In other words, you could deeply namespace your values, and then if you needed something more concise, you could just make a mixin call in another defined mixin. |
- Added error cases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This changes the game. I'm so excited for this.
@calvinjuarez Not the only one excited :-) But someone should soon warn "gulp-less"! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just noticed that .vscode files were removed in an earlier commit. This one adds them back. I wonder if we just add .vscode/
to the .gitignore?
@TigersWay What's your concern about |
@matthew-dean Did some testing with the command line as I quite love that PR. And no I did not find any break :-) |
Word. I love it. I just noted it 'cause a saw a previous commit remove some .vscode/* files, so I wanted to double-check it's intentional. I'm all about making it easy to debug and move fast. So my approval stands. 👍 |
This is an implementation of less/less-meta#12
I finally did it! After a bit of work, the namespaced feature is, I think, ready to roll. See https://github.com/less/less.js/compare/master...matthew-dean:feature/namespace-value?expand=1#diff-4dc2efdc41b7211e1b32b5afca199bf1 for test examples.
In short, you can access properties and variables from mixins and detached-rulesets, to use them as map-like objects, or just for convenience in retrieving a value.
Summary example:
Will output:
Please check out the branch and try it out!