Less.js: L'utilisation de bin / lessc lance "Le chemin doit être une chaîne. Reçu non défini"

des mises à jour à ce sujet?

oui, des mises à jour?
Je voudrais passer au nœud @ 6 maintenant, c'est LTS mais je ne peux pas tant que cela ne sera pas corrigé

Vous vous demandez quel est le statut de cela? J'obtiens cette erreur avec le nœud 6/7.

J'obtiens également cette erreur.
Comment puis-je compiler mon less avec un fichier de carte séparé?
J'utilise la commande:
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

Comme @jhnns l'a mentionné, il s'avère qu'il recherche un 2ème paramètre pour la sortie (cela n'est pas documenté), donc cela échoue:

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

Cependant, en ajoutant le fichier de sortie en tant que paramètre au lieu de la tuyauterie, cela fonctionne:

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

J'espère que cela vous aide les gars 👍

Donc, en d'autres termes, le correctif approprié serait de "lancer une erreur lorsque le fichier de source de carte est spécifié mais que le css de sortie ne l'est pas", non?
De toute évidence, comme le sourcemap doit faire référence à un fichier css particulier, il n'y a pas de méthode (non vulgaire) pour générer un sourcemap approprié sans css de sortie spécifié, c'est-à-dire que ces lignes de commande n'ont tout simplement aucun sens:

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

Non, cela devrait fonctionner comme avant - ces deux commandes:

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

Devrait afficher ceci comme dernière ligne:

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

Le nom du fichier de sortie CSS n'a aucune importance, seul le lien vers la carte compte.

Le nom du fichier de sortie CSS n'a aucune importance

Pas tout à fait, le sourcemap a le champ file pointant vers le CSS de sortie (bien que je puisse voir que c'est facultatif dans les dernières révisions des spécifications).

Quoi qu'il en soit, eh bien, pour autant que je sache, le problème réside dans cette partie . Il s'agit donc simplement de remplacer le répertoire de sortie css par le répertoire quel qu'il soit (répertoire source?) Si output n'est pas défini.
Eh bien, les RP sont les bienvenus (personnellement, je n'utilise pas de sourcemaps et je n'ai aucune idée des options qui peuvent être interrompues par ces changements pour tester davantage).

La prise en charge des cartes sources externes avec la tuyauterie n'offre aucune valeur fonctionnelle. Il offre uniquement aux utilisateurs * nix la convention de rediriger vers un fichier plutôt que de spécifier un paramètre de sortie réel.

Cela n'a aucun sens de générer une carte source externe, puis de diriger le css de sortie vers une autre opération.

La tuyauterie implique que d'autres changements se produisent dans la ou les étapes suivantes de la chaîne, ou que le CSS (et la carte source) soient consommés pour être servis par une application de serveur Web à l'étape finale.

Toute modification apportée à la sortie CSS par Less invaliderait la carte source que Less avait générée. Pour rendre la carte source à nouveau valide, vous devez suivre ces modifications dans une autre carte source, puis la fusionner avec la sortie d'origine par Less pour créer une carte source composée qui restaure le mappage au contenu correct dans les fichiers d'origine .less .

Tout ce qui se trouve plus loin dans la chaîne des opérations canalisées n'aurait plus aucune référence à la carte source externe, car il n'est pas envoyé dans le tuyau. Ainsi, il ne peut pas faire cela et vous êtes toujours coincé avec un sourcemap cassé.

Et bien sûr; si la dernière étape de la chaîne est destinée à servir le css compilé et la carte source: même problème. Aucune référence à la carte. (De toute façon, comment allez-vous servir les deux fichiers en réponse à une seule demande? Intégrer le sourcemap? Alors pourquoi ne pas compiler le moins avec une carte en ligne pour commencer?)

Je préférerais la clarté et le guidage de l'utilisateur (par exemple «tomber dans le gouffre du succès») pour interdire une combinaison d'opérations qui ne peuvent conduire qu'à des problèmes avec les artefacts générés.

La prise en charge des cartes sources externes avec la tuyauterie n'offre aucune valeur fonctionnelle. Il offre uniquement aux utilisateurs * nix la convention de rediriger vers un fichier plutôt que de spécifier un paramètre de sortie réel.

Convenu. Si un nom de fichier de sortie doit être spécifié, il doit être spécifié comme argument du compilateur lessc .

Cela dit, la tuyauterie était-elle documentée dans le passé? Sinon, c'est un point discutable et nous pouvons simplement documenter le comportement actuel. Si tel est le cas, nous devons nous efforcer de documenter les comportements passés et actuellement non pris en charge.

Cela dit, la tuyauterie était-elle documentée dans le passé?

La tuyauterie fonctionne en redirigeant les flux tels que stdout ou stderr. Lorsque lessc ne reçoit pas de nom de fichier de sortie, il sort dans stdout. En ce sens, la tuyauterie a toujours été officiellement soutenue et devrait continuer à l'être. Vous casseriez probablement beaucoup de cas d'utilisation sains autrement pour les personnes qui comptent sur des tuyaux pour communiquer juste à temps moins de fichiers compilés à n'importe quelle application serveur a besoin de les servir en tant que css.

Si vous souhaitez utiliser la tuyauterie avec une carte source, c'est toujours possible de manière sensée:
vous devez en faire une carte source en ligne, puis vous fier à d'autres étapes de traitement dans le tube pour décoder la carte en ligne; y fusionner les modifications; et réappliquez-le en tant que carte source en ligne chaque fois que ces étapes modifient davantage le CSS qui a été compilé par le compilateur lessc.

Ensuite, si vous voulez une carte source externe pour des raisons de performances, c'est-à-dire éviter que les octets supplémentaires de la carte en ligne ne soient livrés à tous les visiteurs. - la dernière étape du pipeline doit interrompre la carte source en ligne et générer deux fichiers: un fichier css et un fichier de carte.

Cela n'a aucun sens de générer une carte source externe, puis de diriger le css de sortie vers une autre opération.

La tuyauterie implique que d'autres changements se produisent dans la ou les étapes suivantes de la chaîne, ou que le CSS (et la carte source) soient consommés pour être servis par une application de serveur Web à l'étape finale.

Je ne suis pas d'accord avec le sentiment cité, et je pense qu'il est incorrect de supposer ce qui se trouve de l'autre côté d'un tuyau donné. Que faire si le tube est téléchargé quelque part? Que faire si le canal sert le CSS résultant, mais que le client n'a pas toujours besoin du sourcemap?

Étant donné que l'indicateur --source-map-url est implémenté, je pense que ce cas d'utilisation devrait être pris en charge.

Dans tous les cas, les utilisateurs ne devraient pas voir d'erreurs impénétrables, en particulier lors de la transmission d'indicateurs du texte d'aide.

Juste mes 2 cents après avoir été bloqué par ce problème.