@use + @import

[chrisui]

Just an idea for a nice feature.

Currently if you're parsing two separate less files on the same page and they need to import the same file, to maybe use variables or extend classes, then you will end up with duplicate code compiled due to the current functionality of @import.

What I propose is the creation of @use which would essentially function exactly like @import but the contents of the file loaded would not be compiled into the final CSS.

Just wondering what people think, if there is a fork for this or even if it's on the roadmap?

[joeldrapper]

@chrisui If your just using your import for variables and mixins, they won't be loaded into the final CSS anyway apart from where they are used. Just make sure even if your mixins don't have any parameters, you still write them like this .variable() with the brackets after the selector, then they won't compile as a class.

[chrisui]

@joeldrapper Yes, thanks, I know this. :)

But with the functionality I propose you could re-use, for example, a file containing all your form classes and then extend such a class without having it compiled. That way you can continuously extend classes instead of having to create a bunch of mixins.

Maybe just a better way of structuring my classes so they extend from core mixins would be a good idea. I'll have to have a think and do some research!

[andreyvit]

+1 on this, there is more than one case where this would come in handy.

[phobia]

+1 on from me as well. This would solve some issues I'm having with having media queries as separate files, but still being able to "extend" classes without having the entire imported sheets rendered as well.

[cerevka]

+1 I think this will be great feature. I use modular architecture so every component has own CSS/LESS file and each of them needs reuse some definition. I have another tool for include all CSS definition into one file dynamically. I use less-maven-compiler, so main.less is for me unusable.

[lukeapage]

Some of this should be covered by the import-once statement.. but I see there is still a usecase for it when using libraries.

[ztane]

+1 here, came to report this as an issue. For example I want to make some existing Bootstrap styles available for specific HTML code, I could for example @use "bootstrap.less" and make table.class { .bootstrap-rule }, and still include both original bootstrap file and my modified file with just a handful of rules.

[matthew-dean]

I think the problem is more specifically how people are writing their LESS libraries than how LESS is consuming / compiling them. Ideally, a LESS library would allow an author to create a default set of styles or not. Bootstrap is very useful, but it doesn't pass the test for playing well with others, which is why you have this problem. It creates a lot of default styling, much of which you may not want or need.

Rather than re-architecting LESS to address the problems of a library that's overly greedy with supplying styles, I think it's better to take up with the authors of those libraries, since some simple changes could allow you to pick and choose sections of styles as you need.

Maybe that misses the original question, but I just want to make sure we're not putting in features that workaround poor practices, if there's a valid way to write your LESS so that it's not needed.

[ztane]

It does miss the point. We do want to include all bootstrap styles, but we have some third-party content that we want to style as well, and were hoping we could just include another sheet which reassigns some of the existing styles for another set of classes without much hassle. For example, we would like table.someclass look like .table-striped.

[lukeapage]

I personally think there is some use to this and think we should address this with the other import changes for 1.4.0

all very well saying bootstrap should change.. and I think it would beenfit them to modularise things and then have mixins you can call for each module, but it allows alot less control over picking things you want. also the use-case from @ztane.

We are already looking at import css directly and import as less.

I don't think it would be too hard to implement.

[jonschlinkert]

So basically, this request would enable you to convert any imported library of styles into quasi-mixins? Accept you would also get the selectors, not just the declarations of referenced styles?

I think we should discuss the use cases and examples of what exactly would get pulled in, in such instances. And what wouldn't get pulled in.

Also, to @agatronic's point about import changes for 1.4.0. I think we need a more versatile syntax for imports/includes that allows us to add features like this in the future without having to come up with another entirely new directive. Our approach with new directives for each use case (@include, @import, @import-once, @import-multiple, @use, etc.) feels kind of hacky. I'm glad we have the functionality that resulted from the import supplements, but it won't scale.

My 2 cents is that we try to solve this by augmenting only the @import directive itself - and only the @import directive. It just feels more CSS-ish. And it's clean. BTW, this was the kind of use case I was imagining for the @options directive, allowing us to add these things as options directly in the LESS without having to add new directives.

[matthew-dean]

+1 to eliminating keywords / collapsing @import directives under @import.

[lukeapage]

yes, I agree @import-X feels hacky and doesn't scale. what do you two mean exactly by augmenting only the @import directive? @option import-silent, import-less { @import "library.css"; } feels a bit ott - is that what you mean? @import [silent|css|less|explicit] file.less for the options, I guess thats what you@matthewdl are saying you don't want.. whats the alternative?

[jonschlinkert]

@agatronic sounds like we're in agreement about the first part with @import-x, as for augmenting the @import directive, I gave some ideas here #560

You gave some feedback on some of those ideas somewhere, I'll need to look for that. In any case they're just ideas to spur discussion. Maybe we should aggregate the issues related to this topic of how LESS and/or CSS files are imported, "included", "used", appended, concatenated, etc? and then organize them into sub-issues and use the GitHub's check-boxes feature to indicate when one has been eliminated, scheduled etc.:

• 1
• 2

[lukeapage]

moving discussion to a single issue #1185