feature: group import statements

[jonschlinkert]

I mentioned this in another issue but never made it a request of its own. The request is to group import statements together:

@import (reference) {
    "one.less",
    "two.less",
    "three.less",
    "four.less"
}

I suppose we would have to adjust syntax for media queries, maybe something like:

@import (rule) (min-width:400px) {
    "one.less",
    "two.less",
    "three.less",
    "four.less"
}

Another option would be to just group the files together like this:

@import (rules) "one.less, two.less, three.less" (min-width:400px);

But this doesn't seem like a good syntax for a bunch of files like you might have with a lib like Bootstrap.

[jonschlinkert]

Actually, right after I clicked the submit button it occurred to me that this might be accomplished with mixins, but I'm not sure how/if that would work with the new import directives. hmm...

[matthew-dean]

What's the output? The confusing thing for me is that you can't import LESS files "based on a media query", but I get that the desire is to still apply the media query in the CSS post-compile.

What are "reference", "rule", "rules" referring to?

[jonschlinkert]

What's the output?

CSS

What are "reference", "rule", "rules" referring to?

The import directives that were introduced in 1.4.0 / 1.4.1. I used (rule)/(rules) as a catchall for these:

@import (reference) "stylesheet.less";
@import (less) "stylesheet.less";
@import (css) "stylesheet.less";
etc...

Take a look at how SASS allows lists of files in @import statements: http://sass-lang.com/docs/yardoc/file.SASS_REFERENCE.html#directives. This is no different accept we also have import directives that need to be accounted for.

[matthew-dean]

Right. So, just a briefer syntax of grouping? Otherwise the same @import behavior?

I think my main concern is still that it's a bit of a new syntax. CSS or LESS doesn't really have a list format like that.

And I don't see the need. What LESS has now is not really that verbose. Other languages list individual imports, and it never really seems overdone, whereas this adds a new format just for formatting.

I think like where we came to on prefixes, it might be a case of defining things explicitly being the better option.

[jonschlinkert]

I guess you changed your mind?: #1185 (comment)

Anyway, yes this is a feature request for a feature that would be useful to me (and presumably others) based on how I use Less.

What LESS has now is not really that verbose. Other languages list individual imports, and it never really seems overdone, whereas this adds a new format just for formatting.

This indicates that you're missing the point. It has nothing to do with verbosity or cutting down on work. It has to do with achieving much greater control over how external libs are imported and manipulated. IMO, features related to this should be a priority since it's where the CSS spec and other preprocessors are trending.

I've added (and contributed to discussions on) a few different feature requests related to the same core challenge, here are a few of them, but there are threads of this in many other conversations:

• Support file globbing for @imports #1181
• Expose method for @importing LESS files #1241
• Import options #1185 (not created by me, but some of the prior discussion and related feature requests/concepts were mine)
• and now: feature: _index.less #1339

Please try to view these requests through the lens of developer who work with external libraries, such as Bootstrap, or work with theming and component or modules libraries, mixin libraries and so on.

[matthew-dean]

No, I had the same opinion then about the syntax.

Going back to #1185, the CSS-like syntax in the back and forth from @lukeapage and me was more like:

@import (reference) "one.less" "two.less" "three.less" (min-width:400px);

In all honesty, your structure reads better (because the CSS spec is so odd at times), it's just more deviant from spec.

The area where I may have shifted on is on value, and our shift to move from feature expansion to API development. When you're importing bootstrap, you typically import a root-level object (single @import). In bootstrap, you have multiple imports, but those aren't different kinds of imports.

So, I can theoretically see large, complex projects possibly needing multiple groupings like this, but I don't see the clamor for it beyond the theoretical. Is this something you think you would use a lot in your projects? I often import a few libraries, but I don't typically have enough @imports to really benefit from grouping them beyond how I group them with whitespace.

[jonschlinkert]

When you're importing bootstrap, you typically import a root-level object (single @import)

Aha! That's the misconception. One of the biggest complaints about libs like Bootstrap is that you have to do what you just said. With my suggestions, libs become granular and less monolithic.

You should be able to import a single bootstrap component - but alas, you cannot without modifying each individual component to also reference variables.less and mixins.less. One of the things I'm trying to accomplish is to make this less opinionated, and more flexible.

Is this something you think you would use a lot in your projects?

It's not theoretical, I do actually currently use these things in my projects: assemble-lib. But I'm having to use non-native-Less.js hacks to accomplish what I need.

"grouping imports" is besides the point here. Matthew you and I clearly use Less differently, so it's difficult to make a point or convince you of something that you have no experience with. I'm not sure what to say.

[matthew-dean]

How would grouping solve Bootstrap modularity? Wouldn't the key to that being that you could declare dependency statements in the individual components? Can you provide theoretical usage, using Bootstrap as a specific example?

So, like, if I just wanted to use the grid portion of Bootstrap (if that's what you're saying), how would grouping help solve that usage? I'd like to understand this.

[jonschlinkert]

Sorry, that came out wrong. I meant that by your own words, you don't do the kind of development I'm describing, and you weren't seeing the value. I'll hop back on late tonight and answer your other questions. Then we should have that call (tomorrow?) and I'll show you some examples if we have time

Sent from my iPhone

On May 23, 2013, at 2:31 PM, Matthew Dean notifications@github.com wrote:

How would grouping solve Bootstrap modularity? Wouldn't the key to that being that you could declare dependency statements in the individual components? Can you provide theoretical usage, using Bootstrap as a specific example?

So, like, if I just wanted to use the grid portion of Bootstrap (if that's what you're saying), how would grouping help solve that usage? I'd like to understand this.

it's difficult to make a point or convince you of something that you have no experience with

ಠ_ಠ Really?

—
Reply to this email directly or view it on GitHub.

[matthew-dean]

Fari enough. LESS allows a lot of use cases. I think in general you have a more modular approach to development, and I work a lot in languages and environments that favor hierarchies and tree structures.

An interesting thought I had on the modular approach, relating to decencies. We should start advocating this pattern:

// base file
@import "variables.less";
@import "mixins.less";
@import "buttons.less";
@import "grid.less";

// file: buttons.less
@import "variables.less";
@import "mixins.less";
...

// file: grid.less
@import "variables.less";
@import "mixins.less";
...

Because the default behavior of @import is now to import once, this pattern would allow you to define your dependencies, so that if someone wanted to just import, say, grid.less, they could do so without breaking the build.

In fact, I was going to say it was too bad you couldn't define dependencies for each LESS file, until I shortly after realized that you could. :-)

[matthew-dean]

@jonschlinkert Revisiting, this seems reasonable. A lot of @imports in a row doesn't read very well. Even if there are no "super-close CSS parallels", the syntax is fairly intuitive.

[jonschlinkert]

👍 agreed. this is something I'm always reminded of when I see sass projects. it's clear from that community that it's not only useful, but it's the preferred way to write out import statements when there are more than a few