Less.js: 使用bin / lessc引发“路径必须是字符串。接收到未定义”

关于此的任何更新？

是的，有任何更新吗？
我想现在移至node @ 6 ，即LTS，但直到解决此问题后再说

想知道这个状况吗？ 我在节点6/7上收到此错误。

我也收到此错误。
如何使用单独的映射文件来编译较少的文件？
我正在使用以下命令：
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

正如@jhnns所提到的，事实证明它正在寻找输出的第二个参数（未记录），因此失败了：

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

但是，将输出文件作为参数添加，而不是通过管道传输可以正常工作：

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

希望对大家有帮助👍

因此，换句话说，正确的解决方法是“当指定了源映射文件但没有输出css时抛出错误”，对吗？
显然，由于源映射必须引用特定的css文件，因此没有（非庸俗的）方法可以生成没有指定css的适当的源映射，即这些命令行完全没有意义：

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

不，它应该像以前一样工作-这两个命令：

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

应该将其作为最后一行输出：

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

CSS输出文件名是完全不相关的，只有指向地图的链接才重要。

CSS输出文件名完全不相关

并非完全如此，sourcemap的file字段指向输出CSS（尽管我可以看到它在最新的规范修订版中是可选的）。

就我所知，无论哪种方式，问题都在这一部分。 因此，如果未定义output则只需用任何目录（sourcemap dir？）替换css输出目录即可。
好吧，PR很不错（我个人不使用sourcemap，也不知道这些更改可以破坏哪些选项以进行进一步测试）。

与管道一起支持外部源图没有任何功能价值。 它仅向* nix用户提供管道到文件的约定，而不是指定实际的输出参数。

生成外部源映射，然后将输出css传递到进一步的操作是没有意义的。

管道意味着在链的下一步中发生进一步的变化，或者在最后一步中消耗CSS（和源映射）以由Web服务器应用程序提供服务。

Less对CSS输出的任何更改都会使Less生成的源映射无效。 要使源映射再次有效，您需要将这些更改跟踪到另一个源映射中，然后将其与Less的原始输出合并，以创建一个复合源映射，该映射将映射还原为原始.less文件中的正确内容。 。

驻留在管道操作链中的任何内容都不再具有对外部源映射的任何引用，因为它不会被发送到管道中。 因此，它无法做到这一点，并且您始终会遇到损坏的源映射。

而且当然; 如果该链的最后一步是要用完已编译的CSS和源映射，则是同样的问题。 没有参考地图。 （无论如何，您将如何将两个文件都作为对一个请求的响应？内联Sourcemap？然后为什么不以内联映射开始编译较少的文件呢？）

我宁愿明确性和用户指导性（例如，“落入成功之坑”）不允许组合操作，这些操作只能导致生成的工件被破坏的问题。

与管道一起支持外部源图没有任何功能价值。 它仅向* nix用户提供管道到文件的约定，而不是指定实际的输出参数。

同意如果要指定输出文件名，则应将其指定为lessc编译器的参数。

也就是说，过去是否记录过管道？ 如果没有，那么这是一个有争议的问题，我们可以记录当前的行为。 如果是这样，那么我们需要重点记录过去和当前不受支持的行为。

也就是说，过去是否记录过管道？

管道通过重定向流（例如stdout或stderr）来工作。 如果没有为lessc提供输出文件名，它将输出到stdout中。 从这个意义上讲，管道一直得到官方的支持，应该继续得到支持。 否则，对于那些依赖管道将即时编译的较少文件传递给服务器应用程序来将它们作为CSS服务的人来说，您可能会打破很多理智的用例。

如果您希望将管道与源映射一起使用，那么仍然可以以理智的方式进行：
您必须将其制作为内联源地图，然后依靠管道中的进一步处理步骤来解码内联地图； 将修改合并到其中； 并在这些步骤进一步修改了由lessc编译器编译的CSS时，将其重新用作内联源映射。

然后，如果您希望出于性能考虑使用外部源映射，即避免将内联映射的其他字节传递给所有访问者。 -管道的最后一步应该断开内联源映射，并输出两个文件：css文件和映射文件。

生成外部源映射，然后将输出css传递到进一步的操作是没有意义的。

管道意味着在链的下一步中发生进一步的变化，或者在最后一步中消耗CSS（和源映射）以由Web服务器应用程序提供服务。

我不同意所引用的观点，并且我认为假设任何给定管道的另一端都存在错误是不正确的。 如果管道上传到某个地方怎么办？ 如果管道正在提供最终的CSS，但客户端并不总是需要sourcemap，该怎么办？

看到--source-map-url标志已实现，我相信应该支持该用例。

无论如何，用户都不会看到难以理解的未捕获错误，尤其是在从帮助文本传递标志时。

被这个问题阻止后，我的收益只有2美分。