Currently, each "less" dependency is being rendered as an individual Less file and this is going against the grain of how Less was designed for a number of reasons:
If an imported Less file produces output and that Less file is imported multiple times by different dependencies then the output will appear multiple times
Common variables must be manually imported to the beginning of every single Less dependency. There is no simple way to make common variables automatically available to all Less dependencies.
Imports that are added inside optimizer.json files are loaded into a string and concatenated with the Less code and this will break things if those imported Less files have @import tags
Solution:
Instead of rendering each Less file individually, simply keep track of all of the encountered Less dependencies and do a single rendering at the end. For example:
That is, every "less" dependency should be thought of as a Less @import statement.
There is one big caveat: all resource urls (e.g. url(foo.png')) inside Less files must be pre-resolved since the optimizer-resolve-css-urls filter would lose the context of the individual Less files on the disks.
In addition, @import statements inside Less files should still work as expected. As a result, we can't simply generate @import statements that point to the original Less file on disk. Instead, we would need to load the Less file from disk and and pre-process it to resolve the URLs. In addition, if that Less file has any @imports then those imports need to be resolved and loaded recursively. In the end, we would then pass a single Less string to the Less renderer that will be similar to the following:
Currently, each "less" dependency is being rendered as an individual Less file and this is going against the grain of how Less was designed for a number of reasons:
optimizer.json
files are loaded into a string and concatenated with the Less code and this will break things if those imported Less files have@import
tagsSolution:
Instead of rendering each Less file individually, simply keep track of all of the encountered Less dependencies and do a single rendering at the end. For example:
optimizer.json:
Given the following
optimizer.json
, the Less renderer should only be called once with the following Less code as input:That is, every "less" dependency should be thought of as a Less
@import
statement.There is one big caveat: all resource urls (e.g.
url(foo.png')
) inside Less files must be pre-resolved since the optimizer-resolve-css-urls filter would lose the context of the individual Less files on the disks.In addition,
@import
statements inside Less files should still work as expected. As a result, we can't simply generate@import
statements that point to the original Less file on disk. Instead, we would need to load the Less file from disk and and pre-process it to resolve the URLs. In addition, if that Less file has any @imports then those imports need to be resolved and loaded recursively. In the end, we would then pass a single Less string to the Less renderer that will be similar to the following: