data-uri function does not respect the "paths" parameter when used via programmatic API

[aldendaniels]

I encountered this issue when using Lessify.

The LESS programmatic API accepts a paths parameter:

less.render('.myclass {...}', {paths: '/a/b/c/'}, function(error, css) {
   ...
});

@import directives correctly resolve file paths relative to the directories in the paths array.

The data-uri() function, by contrast, appears to ignore the paths option - all file paths are resolved relative to the working directory of the node process that invoked the LESS compiler.

---

Needless to day, LESS is an addictively useful tool. Thanks for creating it!

[seven-phases-max]

But that's what this option is supposed to do:

Use this to configure a list of paths which less will use to find imports in.

So the issue seems to be in "using working directory of the node process" instead of "directory of the main less file or the current less file (depending on --relative-url option and so on)".

[aldendaniels]

Hey @seven-phases-max, thanks for the quick reply.

That's true - I made the assumption that data-uri and @import should use the same path resolution logic - an assumption not in the docs. But honestly, why should they differ?

Also, path resolution relative to the "current LESS file" or "main LESS file" isn't helpful when the source is provided to the LESS compiler as string - a common occurrence when LESS is used in conjunction with other build tools such as gulp or browserify. In fact, I couldn't seem to find documentation for invoking the LESS compiler in any other way.

If this issue were to be slightly re-cast as "Make the data-uri() function use exactly the same relative path resolution logic as @import", would there be any drawbacks to that?

[seven-phases-max]

But honestly, why should they differ?

I'm just trying to sort the things to be either an issue/bug report or a feature request for easier tracking. (Obviously the latter needs more deep analysis for possible side-effects and/or conflicts with other features/options).

[lukeapage]

It could be fixed by adding the paths logic to the sync function in the
node file manager (at the moment it is just in async). But i dont really
like that option, it seems to me an option that asks for trouble. Whats
your usecase for needing it to work with data uri ?

[aldendaniels]

@seven-phases-max - makes sense.

@lukeapage -

Whats your usecase for needing it to work with data uri?

I'm compiling LESS via the Lessify browserify plugin, which uses LESS' programatic API. The LESS source needs to include some SVG files as data URIs. I've currently created the data URIs manually, but I'd much rather let LESS do this for me.

For the record (although this is hardly relevant), I'm using Lessify because I need to bundle all source into a single JS file that can be easily dropped onto third party sites. A more common use case would involve grunt or gulp plugins, which would presumably run afoul of the same issue.

[seven-phases-max]

Well, technically if this comes to a library/bundle (contrary to some project-specific stuff) data files I'd said this would be more like anti-pattern to use paths option for this. Just imagine there're two or more such bundles in a project using same file names...
In that case the "standard" way of configuring data-uri paths via variables would be more suitable (especially since you can control those variables both via Less code and/or compiler options, not counting though it will be more tedious to document for relative paths since it also would require --relative-url=on).

[aldendaniels]

I think there may be some confusion. My use case is very normal.

1. I have an SVG image I need to load into my CSS
2. In the bad old days I would manually convert this to a data URL. If I changed the SVG file, I'd have to remember to regenerate the data URL.
3. Thanks to LESS, the bad old days are now over. LESS can automatically load the SVG file off disk and convert it to a data URL using its handy data-uri function.

That's all a textbook use case.

The only problem is that the data-uri function is broken when used via the programmatic API. The relative paths are resolved relative to the build script location. In my case, I include the same LESS code as part of two different build processes, so any relative path will break in one build script or the other.

Going back to the bad-old-days way of doing things isn't the end of the world, but this is clearly missing functionality in LESS.

[seven-phases-max]

In my case, I include the same LESS code as part of two different build processes, so any relative path will break in one build script or the other.

As I mentioned above you can control this path via variables, e.g. some-property: data-uri("@{my-svg-path}/some.svg"); and set my-svg-path in your scripts by globalVars/modifyVars option...

[aldendaniels]

@seven-phases-max - My bad - I misread your comment and thought you were simply suggesting putting the data URL in a variable for readability.

Supplying an absolute path via globalVars would be a functional work-around for the near-term. I still think that better path resolution logic for data-uri would be a welcome improvement, but that's obviously up to you guys to prioritize.

Thanks!

[lukeapage]

Well its not a breaking change, it only effects people using the path
option, which i wouldnt recommend anyway, its nodejs only and its not much
code. I wouldnt be against merging a fix.. would you Max?

[SomMeri]

Fixed by previous commit.