-
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
Support file globbing for @imports #1181
Comments
Cool.. though node only (not browser) and don't think it will help other |
Yeah, no way for the browser to know what files to request, so it seems like a non-starter. |
well I wouldn't rule it out just because it would only apply for node but also I don't see it as a particularly important feature request. |
@agatronic regarding the dependency chain, I was just talking to someone about that same thing at the node meetup yesterday. I think this is something that is useful for component/module libraries, mixins etc. as in the example. And yeah node only was what I was thinking. |
I just read that stylus allow you to specify a directory and if you do that it looks for a as for importing every file in a directory, its only really useful if the files only contain mixins (no content).. because order matters. not sure thats a real-life scenario right now? |
I like the index idea. That's a good way to do it.
We use a lot of component-based development. Most of our Less components have zero dependency on other files. Of course order does matter in CSS and with more traditional design patterns, so I think you're right. Most people probably wouldn't use this the way I would - which mean they wouldn't use it all probably. But the stylus index idea is an interesting solution to this. |
This isn't a priority but I just saw this and wanted to add it as a reference: https://github.com/chriseppstein/sass-globbing |
I'm a huge Sass fan, and I use Chris Eppstein's glob importing plugin all the time (teammates who were on windows machines couldn't use it, so keep that in mind). I've been looking for an equivalent in LESS, anyone see anything like it? |
Yeah I'm a fan of this plugin for sure. I think anyone who has used globbing knows how nice it is to work with, but it's one of those things that seems "nice to have" until you actually use it. I can't imagine trying to do builds without it now. You can use assemble-less, it supports globbing (I'm one of the maintainers of it...) |
Btw @josephspens I created this project yesterday for converting SASS to LESS. As a proof-of-concept, I converted the If you do end up having to use LESS on a project, this might be worth checking out. For some language features, it shouldn't be hard to reverse the process to convert LESS to SASS |
@lukeapage, you mentioned here #1181 (comment) that this would only be useful for mixin libs, and that was true at the time. However, now that we have Also, I thought about the I think the index.less feature would solve an entirely difference challenge, which is more like defining dependencies - really useful for modules, components, themes etc. |
@jonschlinkert I agree |
@lukeapage can you give me a head-start on which places in the code need to be modified (beyond tree/import/.js?), or suggestions for what I need to consider, e.g. should this be specific to node, etc.? I might give it shot. |
This would be a great feature. I currently have a great big long list of stylesheets in my @import 'pages/home';
@import 'pages/login';
@import 'pages/404';
//etc It would be useful to condense this into: @import 'pages/*'; or similar. |
Admins can (either by hand, or in a separate RPM) overwrite the site.less symlink to point at their own custom Less rules, which will be included with Beaker's Less sources when generating CSS. Ideally this would just be a config option of extra filenames which are appended to the 'css' assets bundle. Unfortunately that doesn't work because webassets compiles each Less source file separately, which prevents the site Less rules from overriding or cross-referencing the Beaker ones. In future Less might support @import globs [1] which would allow us to @import site rules from a defined directory. But until then we have to do this ghost symlink hackery. [1] less/less.js#1181 Bug: 1012224 Change-Id: I86f6d6987fd66988a46ec7372bbc3a249f015b46
Stylus allows you to do this -- |
This + explicit import + non-duplicates would be really handy:
|
@lukeapage I'd like to do a plugin for this, can you give me some pointers on where to start? thx |
Sorry Jon that I missed your first request for help, it wasn't intentional. |
Ha, I didn't realize I had already commented, so that makes two of us lol. no worries at all I know how it is.
Sounds good. I'd be happy to help with that too. No worries either way. |
Ok, been thinking and this is how I'd do it.
|
Just wanted to comment, as a workaround, you could use
This is effectively my directory structure... (though, my structure is a little different). I was hoping this was a built-in feature, as even if node-only would be very useful. |
Just thought I'd +1 here... its a pretty common pattern. There's also several easy workarounds for avoiding the order problem. |
@vospascal answered in my repo |
;) thnx @just-boris i saw :-) 👍 |
Still waiting for this feature 👍 . Thanks, @just-boris. |
@just-boris thanks! В смысле, спасибо :-) |
This would be a very useful feature for me, since I prefer to bundle all my components in once place, rather than having all Less files in a single location. This leads to Less files existing all over the place, which would be a nightmare to maintain a manual list of imports for. For anyone using Gulp to build their Less files, I've had success using the gulp-inject plugin to automatically create the |
For globbing in less you can simple simple run this in your project,
then add this to your Gruntfile in the options group of your less task
The result is something like this: ···
options: {
compress: true,
yuicompress: true,
optimization: 2,
cleancss: true,
sourceMap: false,
sourceMapFilename: 'css/maps/style.css.map',
plugins: [require('less-plugin-glob')]
},
··· Now in your .less file you can write this: ···
@import "commons/**/*";
@import "basic/**/*";
··· |
Came here wondering if glob imports were supported, but since I'm using a couple of one-liner shell scripts instead of grunt/gulp for my build process. I ended up just using # src/index.less + src/foo/bar.less + ... = dist/index.css
find -X src -type f -name '*.less' | xargs cat | lessc - | cleancss --s0 >dist/index.css |
+1 |
Really surprised this hasn't happened by now. Gulp has support for this feature at least. |
@davidcalhoun Read the first post in this thread. |
Same, as far as I am aware, most people are compiling their LESS files into CSS , I don't know of many sites that are having the browser interpret the LESS directly? For those that wish to debug, can use source maps |
@just-boris I can't get your plugin to work... I assume I'm doing something wrong. Has anyone else gotten it to work? Not getting any errors... just no output when I try to use globbing.
|
@SpencerCarstens It's better to raise the issue at the plugin own repository. |
I was hoping to reach a greater audience, but you are right. |
@seven-phases-max You can't integrate the glob-plugin inside less? |
It integrates fine, but doesn't seem to do anything. If I comment out the plugin, my less correctly errors on the import When I put it back in, the error stops. So, I assume it's doing something. On Wednesday, August 5, 2015, Mattia Astorino notifications@github.com
Cordially, Spencer Carstens |
If you mean "why to not put this into the core"... Then, well, the current Less approach (less or more set up in several discussions across various threads here) is roughly: "never put a feature to the core, before it becomes absolutely and totally evident the feature belongs there and there's no other ways". That is, if something can be implemented as a plugin it should be implemented as a plugin (that's why for example even long-living-in-the-core |
@seven-phases-max ok, thanks. I like this. |
Closing as implemented in @just-boris 's plugin. |
+1 |
1 similar comment
+1 |
Talk about resurrecting old threads |
What are these +1's supposed to indicate? Is the plugin not workable? |
The +1 indicates that you want or support it too |
Support what? That's what I'm saying. This has been addressed and the issue is closed. So I'm asking what is being +1'd? |
I've been getting these emails for over 2 years what's the deal here.. |
See: https://github.com/isaacs/node-glob,
and
https://github.com/isaacs/minimatchhttps://github.com/jonschlinkert/micromatchI use these often in projects. It would be pretty awesome to be able to do the following and not have to specify individual files:
After only a few minutes of using these patterns they become second nature. It might even help with some of the other import issues.
Implemented via plugin: less-plugin-glob.
The text was updated successfully, but these errors were encountered: