Using bin/lessc throws "Path must be a string. Received undefined"

[jhnns]

As already reported in #2881 and after merging #2891, running lessc --source-map-map-inline styles/main.less in node v6 throws

TypeError: Path must be a string. Received undefined
    at assertPath (path.js:7:11)
    at Object.basename (path.js:1355:5)
    at /Users/jhnns/dev/jhnns/less.js/bin/lessc:311:61
    at Object.<anonymous> (/Users/jhnns/dev/jhnns/less.js/bin/lessc:508:3)
    at Module._compile (module.js:541:32)
    at Object.Module._extensions..js (module.js:550:10)
    at Module.load (module.js:456:32)
    at tryModuleLoad (module.js:415:12)
    at Function.Module._load (module.js:407:3)

This is because an undefined path is passed as basename.

[mykyta-shulipa]

any updates regarding to this?

[mattecapu]

yes, any updates?
I'd like to move to node@6 now that is LTS but I can't until this is fixed

[phillipchengh]

Wondering about the status of this? I get this error with node 6/7.

[pjotrvdh]

I'm getting this error as well..
How am I able to compile my less with an seperate map file?
I'm using the command:
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

[jsguy]

As @jhnns mentioned, It turns out that it is looking for a 2nd parameter for the output (this is not documented), so this fails:

lessc --source-map=test.less.map test.less>test.css

However adding the output file as a parameter instead of piping it works:

lessc --source-map=test.less.map test.less ./test.css

Hope that helps you guys 👍

[seven-phases-max]

So, in other words, the proper fix would be "throw a error when sourcemap file is specified but the output css is not", right?
Obviously since the sourcemap must refer to a particular css file, there's no (non-vulgar) methods to generate a proper sourcemap w/o output css specified, i.e. these command lines simply make no sense:

lessc --source-map=test.less.map test.less
lessc --source-map=test.less.map test.less > test.css

[jsguy]

No, it should work like it used to - those two commands:

lessc --source-map=test.less.map test.less
lessc --source-map=test.less.map test.less > test.css

Should output this as the last line:

/*# sourceMappingURL=test.less.map */

The CSS output file name is completely irrelevant, only the link to the map matters.

[seven-phases-max]

The CSS output file name is completely irrelevant

Not quite, the sourcemap has the file field pointing to the output CSS (though I can see it's optional in the latests spec. revisions).

Either way, well, as far as I can tell the problem is in this part. Thus it's just a matter of replacing the css output dir with whatever dir (sourcemap dir?) if output is not defined.
Well, PRs are wellcome (personally I don't use sourcemaps and have no idea what options can be broken by these changes to test further).

[rjgotten]

Supporting external source maps together with piping offers no functional value. It only affords *nix users the convention of piping to a file rather than specifying an actual output parameter.

It makes no sense to generate an external source map and then pipe the output css to a further operation.

Piping implies further changes happening in the next step(s) of the chain, or the CSS (and source map) being consumed to be served out by a web server application in the final step.

Any changes to the CSS output by Less would invalidate the source map that Less had generated. To make the source map valid again you'd need to track those changes into another source map and then merge that with the original one output by Less to create a compound source map that restores the mapping to the correct contents in the original .less files.

Anything residing further along in the chain of piped operations would not have any reference to the external source map anymore, because it's not sent along into the pipe. Thus it cannot do this and you are always stuck with a broken sourcemap.

And ofcourse; if the final step of the chain is meant to serve out the compiled css and source map: same problem. No reference to the map. (How are you going to serve out both files as response to one request anyway? Inlining the sourcemap? Then why not compile the less with an inline map to begin with?)

I would rather favor the clarity and user-guidance (e.g. 'falling into the pit of success') of disallowing a combination of operations that can only lead to problems with generated artifacts being broken.

[matthew-dean]

Supporting external source maps together with piping offers no functional value. It only affords *nix users the convention of piping to a file rather than specifying an actual output parameter.

Agreed. If an output filename is to be specified, it should be specified as an argument to the lessc compiler.

That said, was piping documented in the past? If not, then it's a moot point and we can just document current behaviour. If so, then we need to make a point of documenting past and currently unsupported behaviour.

[rjgotten]

That said, was piping documented in the past?

Piping works by redirecting streams such as stdout or stderr. When lessc is not given an output filename, it outputs into stdout. In that sense, piping has always been officially supported and should continue to be supported. You'd probably break a lot of sane use-cases otherwise for people that rely on pipes to communicate just-in-time compiled less files to whatever server application needs to serve them out as css.

If you want to use piping together with a source map, that's still possible in a sane way:
you'd have to make it an inline source map and then rely on further processing steps in the pipe to decode the inline map; merge modifications into it; and reapply it as an inline source map whenever those steps further modify the CSS that was compiled by the lessc compiler.

Then, if you want an external source map for performance sake -- I.e. avoiding the additional bytes of the inline map being delivered to all visitors. -- the final step in the pipeline should break the inline source map off and output two files: a css file and a map file.

[jeffawang]

It makes no sense to generate an external source map and then pipe the output css to a further operation.

Piping implies further changes happening in the next step(s) of the chain, or the CSS (and source map) being consumed to be served out by a web server application in the final step.

I disagree with the quoted sentiment, and I think it's incorrect to assume what's on the other side of any given pipe. What if the pipe is uploading to somewhere? What if the pipe is serving the resulting CSS, but the client doesn't always need the sourcemap?

Seeing as the --source-map-url flag is implemented, I believe this use case should be supported.

In any case, users shouldn't be seeing inscrutable uncaught errors, especially when passing in flags from the help text.

Just my 2 cents after having been blocked by this issue.