Less.js: El uso de bin / lessc arroja "La ruta debe ser una cadena. Recibido indefinido"

alguna actualización con respecto a esto?

sí, ¿alguna actualización?
Me gustaría moverme al nodo @ 6 ahora que es LTS pero no puedo hasta que esto se solucione

¿Se pregunta sobre el estado de esto? Recibo este error con el nodo 6/7.

También recibo este error ...
¿Cómo puedo compilar mis menos con un archivo de mapa separado?
Estoy usando el comando:
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

Como mencionó @jhnns , resulta que está buscando un segundo parámetro para la salida (esto no está documentado), por lo que esto falla:

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

Sin embargo, agregar el archivo de salida como parámetro en lugar de canalizarlo funciona:

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

Espero que les ayude chicos 👍

Entonces, en otras palabras, la solución adecuada sería "arrojar un error cuando se especifica el archivo de mapa de origen pero el css de salida no", ¿verdad?
Obviamente, dado que el mapa de origen debe referirse a un archivo css en particular, no hay métodos (no vulgares) para generar un mapa de origen adecuado sin css de salida especificado, es decir, estas líneas de comando simplemente no tienen sentido:

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

No, debería funcionar como solía hacerlo, esos dos comandos:

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

Debería generar esto como la última línea:

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

El nombre del archivo de salida CSS es completamente irrelevante, solo importa el enlace al mapa.

El nombre del archivo de salida CSS es completamente irrelevante

No del todo, el mapa de origen tiene el campo file apunta al CSS de salida (aunque puedo ver que es opcional en las últimas revisiones de especificaciones).

De cualquier manera, por lo que puedo decir, el problema está en esta parte . Por lo tanto, es solo una cuestión de reemplazar el directorio de salida css con cualquier directorio (¿directorio del mapa fuente?) Si output no está definido.
Bueno, los RR.PP. son bienvenidos (personalmente, no uso mapas de origen y no tengo idea de qué opciones pueden romperse con estos cambios para probar más).

La compatibilidad con mapas de fuentes externas junto con las tuberías no ofrece ningún valor funcional. Solo permite a los usuarios de * nix la convención de canalizar a un archivo en lugar de especificar un parámetro de salida real.

No tiene sentido generar un mapa fuente externo y luego canalizar el CSS de salida a una operación adicional.

La canalización implica que se produzcan más cambios en los siguientes pasos de la cadena, o que el CSS (y el mapa de origen) se consuma para ser servido por una aplicación de servidor web en el paso final.

Cualquier cambio en la salida CSS de Less invalidaría el mapa de origen que Less había generado. Para que el mapa de origen vuelva a ser válido, deberá realizar un seguimiento de esos cambios en otro mapa de origen y luego fusionarlo con el resultado original de Less para crear un mapa de origen compuesto que restaure el mapa a los contenidos correctos en los archivos .less originales. .

Cualquier cosa que resida más adelante en la cadena de operaciones canalizadas ya no tendrá ninguna referencia al mapa de origen externo, porque no se envía a la canalización. Por lo tanto, no puede hacer esto y siempre tiene un mapa fuente roto.

Y por supuesto; si el paso final de la cadena está destinado a servir el css compilado y el mapa fuente: mismo problema. Sin referencia al mapa. (¿Cómo va a entregar ambos archivos como respuesta a una solicitud de todos modos? ¿Incluir el mapa de origen? Entonces, ¿por qué no compilar menos con un mapa en línea para empezar?)

Preferiría favorecer la claridad y la guía del usuario (por ejemplo, "caer en el pozo del éxito") de no permitir una combinación de operaciones que solo pueden conducir a problemas con los artefactos generados que se rompen.

La compatibilidad con mapas de fuentes externas junto con las tuberías no ofrece ningún valor funcional. Solo permite a los usuarios de * nix la convención de canalizar a un archivo en lugar de especificar un parámetro de salida real.

Acordado. Si se va a especificar un nombre de archivo de salida, debe especificarse como un argumento para el compilador lessc .

Dicho esto, ¿se documentaron las tuberías en el pasado? Si no, entonces es un punto discutible y podemos simplemente documentar el comportamiento actual. Si es así, entonces debemos asegurarnos de documentar el comportamiento pasado y actualmente sin apoyo.

Dicho esto, ¿se documentaron las tuberías en el pasado?

La canalización funciona redirigiendo corrientes como stdout o stderr. Cuando no se le da un nombre de archivo de salida a lessc, se genera en stdout. En ese sentido, la tubería siempre ha tenido soporte oficial y debe seguir siendo compatible. De lo contrario, probablemente rompería muchos casos de uso cuerdos para las personas que dependen de las tuberías para comunicarse justo a tiempo con menos archivos compilados a cualquier aplicación de servidor que necesite servirlos como css.

Si desea usar tuberías junto con un mapa de origen, aún es posible de una manera sensata:
tendría que convertirlo en un mapa de origen en línea y luego confiar en los pasos de procesamiento adicionales en la tubería para decodificar el mapa en línea; fusionar modificaciones en él; y vuelva a aplicarlo como un mapa fuente en línea siempre que esos pasos modifiquen aún más el CSS que fue compilado por el compilador lessc.

Luego, si desea un mapa de origen externo por motivos de rendimiento, es decir, evitar los bytes adicionales del mapa en línea que se entregan a todos los visitantes. - el último paso en la canalización debería romper el mapa de origen en línea y generar dos archivos: un archivo css y un archivo de mapa.

No tiene sentido generar un mapa fuente externo y luego canalizar el CSS de salida a una operación adicional.

La canalización implica que se produzcan más cambios en los siguientes pasos de la cadena, o que el CSS (y el mapa de origen) se consuma para ser servido por una aplicación de servidor web en el paso final.

No estoy de acuerdo con el sentimiento citado y creo que es incorrecto asumir lo que está al otro lado de cualquier tubería dada. ¿Qué pasa si la tubería se está cargando en algún lugar? ¿Qué sucede si la tubería sirve el CSS resultante, pero el cliente no siempre necesita el mapa de origen?

Dado que se implementa la bandera --source-map-url , creo que este caso de uso debería ser compatible.

En cualquier caso, los usuarios no deberían ver errores inescrutables no detectados, especialmente al pasar banderas del texto de ayuda.

Solo mis 2 centavos después de haber sido bloqueado por este problema.