Imports directives should support globbing
MarcDiethelm opened this issue · comments
The function processDirective uses the incoming directives literally. Globbing is not implemented and if used the import will fail.
Globbing would however be very useful for the @import (reference) use case. That's how I tried to use it anyway: Throw all files containing variables, mixins, helpers (own or vendor) in a lib folder and let Less sort out what's actually needed.
here you go... please test this out when you get a chance, I'm not quite ready to publish this to npm. Note that if you use broad and general globbing patterns with import directives, your build will be slow as hell. Something to keep in mind.
There are things we can do to speed it up, but I'd like to get some feedback before I spend more time on it.
Awesome, thank you. Basic testing reports no problems so far.
...your build will be slow as hell
Yeah, I was wondering about that. We'll be testing this in a frontend templating project. Expect me to report back with my findings once the project has grown.
👍 just to be clear though... if you, for instance, reference all of the Bootstrap components, then each Bootstrap component will be "scanned" for each file referencing those components. you'll see that I'm explicitly referencing only a couple of Bootstrap files in the reference example in the Gruntfile, this is because it took like 30 seconds to build when I had it scanning the entire directory....
I'm wondering how it will perform in my case... Before compiling with assemble-less I'm using grunt-less-imports, which creates a temporary file where all the project styles are listed as @import statements. I'm then feeding this file to assemble-less to reference dependencies and compile.
Does this improve performance or are the references still scanned for every (classically) imported file? I'm speculating that the imports are all part of the same tree and scanning the refs only takes place once per tree... Correct?
I'm speculating that the imports are all part of the same tree and scanning the refs only takes place once per tree
Natively, in Less.js this is the case. but the way I'm doing it in the plugin, no. the tree is constructed on the fly AND scanned for each file. so this definitely needs to be optimized (per my comment after the commit). and I'm not sure of the best way to implement yet... I just haven't given this enough thought yet
By the way, where can I find infos about the new directives in less and their meanings?
where can I find infos about the new directives in less and their meanings?
You can't yet lol, I'm doing the docs and I'm terribly behind. I'm working on it now though!