Less.js: O uso de bin / lessc lança "O caminho deve ser uma string. Recebido indefinido"

alguma atualização em relação a isso?

sim, alguma atualização?
Eu gostaria de mover para o nó @ 6 agora que é LTS, mas não posso até que isso seja corrigido

Quer saber sobre o status disso? Recebo este erro com o nó 6/7.

Estou recebendo este erro também ..
Como posso compilar meu less com um arquivo de mapa separado?
Estou usando o comando:
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

Como @jhnns mencionou, Acontece que ele está procurando um segundo parâmetro para a saída (isso não está documentado), então falha:

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

No entanto, adicionar o arquivo de saída como um parâmetro em vez de canalizar funciona:

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

Espero que ajude vocês 👍

Portanto, em outras palavras, a correção adequada seria "lançar um erro quando o arquivo sourcemap for especificado, mas o css de saída não for", certo?
Obviamente, uma vez que o mapa de origem deve se referir a um arquivo css específico, não há métodos (não vulgares) para gerar um mapa de origem adequado sem css de saída especificado, ou seja, essas linhas de comando simplesmente não fazem sentido:

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

Não, deve funcionar como antes - esses dois comandos:

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

Deve imprimir isso como a última linha:

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

O nome do arquivo de saída CSS é completamente irrelevante, apenas o link para o mapa é importante.

O nome do arquivo de saída CSS é completamente irrelevante

Não exatamente, o mapa de origem tem o campo file apontando para o CSS de saída (embora eu possa ver que é opcional nas últimas revisões de especificações).

De qualquer forma, bem, pelo que posso dizer, o problema está nesta parte . Portanto, é apenas uma questão de substituir o dir de saída css por qualquer dir (dir do mapa de origem?) Se output não estiver definido.
Bem, PRs são bem-vindos (pessoalmente eu não uso mapas de origem e não tenho ideia de quais opções podem ser quebradas por essas mudanças para testar mais).

O suporte a mapas de origem externa junto com tubulação não oferece nenhum valor funcional. Ele oferece apenas aos usuários * nix a convenção de canalizar para um arquivo, em vez de especificar um parâmetro de saída real.

Não faz sentido gerar um mapa de origem externa e, em seguida, canalizar o css de saída para uma operação posterior.

O encanamento implica mudanças adicionais acontecendo na (s) próxima (s) etapa (s) da cadeia, ou o CSS (e o mapa de origem) sendo consumido para ser servido por um aplicativo de servidor da web na etapa final.

Quaisquer alterações na saída CSS por Less invalidariam o mapa de origem que Less havia gerado. Para tornar o mapa de origem válido novamente, você precisa rastrear essas alterações em outro mapa de origem e, em seguida, mesclá-lo com a saída original de Less para criar um mapa de origem composto que restaura o mapeamento para o conteúdo correto nos arquivos .less originais .

Qualquer coisa que resida mais ao longo da cadeia de operações canalizadas não teria mais nenhuma referência ao mapa de origem externa, porque não é enviado ao longo do cano. Portanto, ele não pode fazer isso e você está sempre preso a um mapa de origem corrompido.

E claro; se a etapa final da cadeia for destinada a servir o css compilado e o mapa de origem: o mesmo problema. Nenhuma referência ao mapa. (Como você vai servir os dois arquivos como resposta a uma solicitação de qualquer maneira? Incluindo o mapa de origem? Então, por que não compilar o less com um mapa embutido para começar?)

Prefiro a clareza e a orientação do usuário (por exemplo, 'cair no poço do sucesso') de proibir uma combinação de operações que só pode levar a problemas com artefatos gerados sendo quebrados.

O suporte a mapas de origem externa junto com tubulação não oferece nenhum valor funcional. Ele oferece apenas aos usuários * nix a convenção de canalizar para um arquivo, em vez de especificar um parâmetro de saída real.

Concordou. Se um nome de arquivo de saída deve ser especificado, ele deve ser especificado como um argumento para o compilador lessc .

Dito isso, a tubulação foi documentada no passado? Se não, então é um ponto discutível e podemos apenas documentar o comportamento atual. Nesse caso, precisamos documentar o comportamento passado e atualmente sem suporte.

Dito isso, a tubulação foi documentada no passado?

A tubulação funciona redirecionando fluxos como stdout ou stderr. Quando lessc não recebe um nome de arquivo de saída, ele sai em stdout. Nesse sentido, a tubulação sempre foi oficialmente apoiada e deve continuar a receber. Você provavelmente quebraria muitos casos de uso lógicos, caso contrário, para pessoas que dependem de canais para comunicar menos arquivos compilados just-in-time para qualquer aplicativo de servidor que precise servi-los como css.

Se você quiser usar tubulação junto com um mapa de origem, isso ainda é possível de uma maneira sã:
você teria que torná-lo um mapa de origem embutido e então contar com as etapas de processamento adicionais no tubo para decodificar o mapa embutido; mesclar modificações nele; e reaplicá-lo como um mapa de origem embutido sempre que essas etapas modificarem ainda mais o CSS que foi compilado pelo compilador lessc.

Então, se você quiser um mapa de origem externa para fins de desempenho - ou seja, evitando que os bytes adicionais do mapa em linha sejam entregues a todos os visitantes. - a etapa final no pipeline deve interromper o mapa de origem embutido e gerar dois arquivos: um arquivo css e um arquivo de mapa.

Não faz sentido gerar um mapa de origem externa e, em seguida, canalizar o css de saída para uma operação posterior.

O encanamento implica mudanças adicionais acontecendo na (s) próxima (s) etapa (s) da cadeia, ou o CSS (e o mapa de origem) sendo consumido para ser servido por um aplicativo de servidor da web na etapa final.

Não concordo com o sentimento citado e acho incorreto presumir o que está do outro lado de um determinado cano. E se o pipe estiver carregando para algum lugar? E se o pipe estiver servindo ao CSS resultante, mas o cliente nem sempre precisar do mapa de origem?

Vendo como o sinalizador --source-map-url é implementado, acredito que este caso de uso deve ser suportado.

Em qualquer caso, os usuários não deveriam estar vendo erros inescrutáveis ​​não detectados, especialmente ao passar sinalizadores do texto de ajuda.

Apenas meus 2 centavos depois de ter sido bloqueado por esse problema.