[Feature request] - Import directory

[alexwhitman]

I've got a number of modules I'm writing styles for, one file per module, and currently I'm importing each .less file. Instead it would be useful to just able to @import 'directory_of_files/' which would include all of the less/css files in the directory.

[ivanovyordan]

How do you imaginate this? This is impossible. LESS is a cliend-side javascript solution. What you are looking should be a server-side solution.

[cloudhead]

LESS is both client and server, depending on preference.. I could look into this if I have time.

[paulogaspar7]

Ordering not important?

[alexwhitman]

Ordering could be an issue but in my use case I've got a 'modules' directory which has styles for different modular components (each module has a .less file) where it doesn't matter what order they get included in.

[roblafeve]

@whitman, did you ever find the solution?

[alexwhitman]

@roblafeve I didn't. In the end it wasn't really an issue to just add the individual files. It could still be a useful thing though.

[matthew-dean]

I think this would break client-side functionality. The web page doesn't know what files exist on the server, hence it can't import a directory without a server-side script. Because of that, and since another solution was found, I recommend closing this issue.

[lukeapage]

Seconded.

[hypesystem]

I still think this would be a great feature server-side. "This is hard" is hardly an excuse to close it.

[lukeapage]

reopened
as long as it fitted into our new environment system so it would essentially give the environment a path and ask for a list of files and the browser environment could throw an error - not supported then I think this would be useful, if low priority addition.

There is another issue thats similiar knocking around too.

[matthew-dean]

@lukeapage Duplicate of #1181 and #1413 (or those are duplicates of this).

[matthew-dean]

Also, yes, with a proper return value of either the directory list or "not supported", this would probably be okay at that point.

[davidcalhoun]

This would be extremely useful. It would also be a nice advantage over using SASS, which also doesn't have this feature.

[neemzy]

I've got to +1 this :) I can live without it but it would be a great improvement to me to have this feature. Well, that was my 2 cents !

[jonschlinkert]

I now think this is something best implemented with a plugin. I'd rather see the API evolve so that the various approaches to file loading are kept out of Less.js core, which (IMHO) should really be focused on parsing.

if we were to add this to less.js core though, I think #1181 would be much more advantageous, since globbing patterns allow you to load directories of files, specific files, exclude files or extensions, and so on.

[matthew-dean]

I now think this is something best implemented with a plugin.

@jonschlinkert I'm starting to lean that way too, especially as the API / plugin stuff is gaining momentum. I'm even thinking we should consider moving anything from core to plugins that isn't cross-platform (Node/Rhino/Browser), such as data-uri.

Which of course, means this issue is still valid, it just may be addressed in a different way, yes?

[jonschlinkert]

moving anything from core to plugins that isn't cross-platform (Node/Rhino/Browser)

Lol, I was thinking the opposite. If you think about it (if @lukeapage, @seven-phases-max et al had unlimited time, desire, and incentive to do so) ideally the core would be focused on code that is platform agnostic, leaving platform implementations to other "contrib" projects, e.g less-cli, less-node, less-rhino, less-browser etc, and then plugins would handle application code and edge cases. As with many other plugin-oriented tools, it would be trivial enough to init new projects with your favorite less-contrib and less user-plugins.

I'm personally in favor of this route. I can envision a time when the issues on Less.js are almost entirely related to language features, parsing, and related performance and reliability. While other libs would be created to deal with file loading, environment differences, CLI, etc.

[jonschlinkert]

wait, I just re-read lol. you said the same thing. I read it backwards the first time... I read "isn't cross-platform" as "is cross-platform".

anyway, good stuff!

[matthew-dean]

^_^

I think we're all on the same page.

[lukeapage]

Technically its easier to change less so that it asks its environment for a
list of files for an import and then its up to the environment -
node/browser/rhino etc to either do that, error or return what it was given.

Because of the way imports work this particular feature will be harder to
do as a plugin, but yes it can be environment specific.

[steelbrain]

Bump!

[lukeapage]

merging with #1181