Feature request: "resolve @import only" mode

[arcanis]

I think it would be great to have a way to generate a single less file from another set of files. For example, the following:

foo.less

@import "./bar.less";
body { color: my-body-color; }

bar.less

my-body-color: red;

Would give

output.less

my-body-color: red;
body { color: my-body-color; }

Instead of

output.css

body { color: red; }

It would be very useful, together with the !default feature.

[matthew-dean]

Why? How is it useful?

[lukeapage]

It would require the format less feature as a pre-requisite too.

I'm guessing its so that a library can provide a single less file instead if multiple less files.

[arcanis]

The main use case would be exactly like what @lukeapage said : serving a single less file instead of multiple ones. A single file is often easier to version-manage and add into a build system (even if it's not totally impossible to use a directory).

This proposal is linked to the mentionned issue, but is not driven by it; both of them were required to fit what I had in mind (which you may or may not want to implement).

As a side note, you've been really fast to react on both issues!

[matthew-dean]

It would require the format less feature as a pre-requisite too.

Maybe not. It sounds like it would be an as-is inline dump of the contents of the Less file at the point of @import. BUT my guess is that's not a trivial change in flow, since currently Less files are fully imported into the AST, and then converted / formatted back out to CSS, if I'm not mistaken. And it sounds like a fairly custom feature. I would think at the least it would be a parse plugin, that takes the contents after import (and before render) and simply allows you to pull out the strings of each file and concatenate them.

[seven-phases-max]

A single file is often easier to version-manage and add into a build system

So I don't get it. Initially you create and edit a multifile project then "compile" it to a singe file and then keep editing the "compiled" version? Hmm... This sounds at least strange.

[lukeapage]

I think the idea is libraries would produce a versioned single .less file
in their release as well as a single css file. And that is marginally
easier than getting all bootstrap at a particular tag and copying the less
folder.

I'm not sure its worth it, but if less were extended to pretty print (or a
tool built on top more likely) it wouldnt be difficult. If its a tool that
regexs for imports, thats a completely seperate project, not currently
requiring any of less that anyone is free to go and write.

[lukeapage]

Rereading actually

I would think at the least it would be a parse plugin, that takes the
contents after import (and before render) and simply allows you to pull out
the strings of each file and concatenate them.

If less was modified to allow a pre-import visitor you could create a
visitor plugin and post processor plugin, with the visitor recording the
location of the import statements and the post processor making its own
output. Might be more difficult than doing from scratch though.

[arcanis]

BUT my guess is that's not a trivial change in flow, since currently Less files are fully imported into the AST

If the files are directly put into the AST, wouldn't a visitor walking over the resulting AST be enough ? I'm not sure how less works, but according to the other thread, the variables are lazy loaded, so I guess that there is a step between the @import resolution and the rest of the processing where something could be plugged.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rulatir]

I have a good use case for this: a huge Less codebase with lots of @imports but originally developed with offline compilation in mind. Custom file managers are used that can't be easily ported to browser. New requirement arises: a theme editor with live preview powered by modifyVars(). Can't send unmodified LESS to browser, it won't work.

[seven-phases-max]

I have a good use case for this

I'm afraid it's not good enough to be worth almost doubling the compiler code. (Yet again the compiler parses the input Less code into internal AST format where every language entity is represented with a JS object and then there's nothing that can convert these JS objects of various types back to corresponding Less text).

[rulatir]

High on my "regulations that would be 1000× more useful than the cookie law" list: ban parsers that don't store enough info in the AST to enable character-for-character reconstruction of the input. I hope @import nodes at least store the line number? Looks like something that would be needed for sourcemaps.

[seven-phases-max]

ban parsers that don't store enough info in the AST to enable character-for-character

Yet again, it does store all the info for reconstruction, it's just the reconstruction itself would require a bloat of new code (yet again because the AST is designed specifically to produce CSS after language statements are evaluated... That's why it's named a compiler and not a "text-search-and-replace-library").

1000× more useful

And why not x1001?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.