Less.js: bin / lesscを使用すると「パスは文字列でなければなりません。未定義で受信されました」

これに関する更新はありますか？

はい、更新はありますか？
今はLTSであるnode @ 6に移動したいのですが、これが修正されるまで移動できません

これの状況について疑問に思いますか？ ノード6/7でこのエラーが発生します。

このエラーも発生します。
別のマップファイルを使用してlessをコンパイルするにはどうすればよいですか？
私は次のコマンドを使用しています：
lessc --no-color test.less --source-map=test.css.map -source-map-url=test.css.map

@jhnnsが述べたように、出力の2番目のパラメーターを探していることが判明したため（これは文書化されていません）、これは失敗します。

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

ただし、出力ファイルをパイプではなくパラメーターとして追加すると、次のように機能します。

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

それが皆さんのお役に立てば幸いです👍

つまり、適切な修正は、「ソースマップファイルが指定されているが、出力cssが指定されていない場合にエラーをスローする」ということです。
明らかに、ソースマップは特定のcssファイルを参照するはない）メソッドはありません。つまり、これらのコマンドラインは単に意味がありません。

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

いいえ、以前と同じように機能するはずです-これらの2つのコマンド：

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

これを最後の行として出力する必要があります。

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

CSS出力ファイル名は完全に無関係であり、マップへのリンクのみが重要です。

CSS出力ファイル名は完全に無関係です

完全ではありませんが、ソースマップには出力CSSを指すfileフィールドがあります（ただし、最新の仕様リビジョンではオプションであることがわかります）。

いずれにせよ、まあ、私が知る限り、問題はこの部分にあります。 したがって、 outputが定義されていない場合は、css出力ディレクトリを任意のディレクトリ（ソースマップディレクトリ？）に置き換えるだけです。
ええと、PRは大歓迎です（個人的にはソースマップを使用しておらず、さらにテストするためにこれらの変更によってどのオプションが壊れる可能性があるのか​​わかりません）。

配管とともに外部ソースマップをサポートしても、機能的な価値はありません。 * nixユーザーには、実際の出力パラメーターを指定するのではなく、ファイルにパイプするという慣習しかありません。

外部ソースマップを生成してから、出力cssを別の操作にパイプすることは意味がありません。

パイピングは、チェーンの次のステップで発生するさらなる変更、または最終ステップでWebサーバーアプリケーションによって提供されるために消費されるCSS（およびソースマップ）を意味します。

LessによるCSS出力への変更は、Lessが生成したソースマップを無効にします。 ソースマップを再び有効にするには、これらの変更を別のソースマップに追跡し、それをLessによって出力された元のマップとマージして、マッピングを元の.lessファイルの正しい内容に復元する複合ソースマップを作成する必要があります。 。

パイプ操作のチェーンのさらに先にあるものは、パイプに送信されないため、外部ソースマップへの参照がなくなります。 したがって、これを行うことはできず、常に壊れたソースマップで立ち往生しています。

そしてもちろん; チェーンの最後のステップがコンパイルされたcssとソースマップを提供することを意図している場合：同じ問題。 地図への参照はありません。 （とにかく、1つの要求への応答として両方のファイルをどのように提供しますか？ソースマップをインライン化しますか？それでは、最初にインラインマップを使用してlessをコンパイルしませんか？）

私はむしろ、生成されたアーティファクトの破損にのみつながる可能性のある操作の組み合わせを許可しないという明確さとユーザーガイダンス（たとえば、「成功の落とし穴に陥る」）を好みます。

配管とともに外部ソースマップをサポートしても、機能的な価値はありません。 * nixユーザーには、実際の出力パラメーターを指定するのではなく、ファイルにパイプするという慣習しかありません。

同意しました。 出力ファイル名を指定する場合は、 lesscコンパイラーへの引数として指定する必要があります。

そうは言っても、配管は過去に文書化されていましたか？ そうでない場合、それは論点であり、現在の動作を文書化することができます。 もしそうなら、過去と現在サポートされていない行動を文書化することを強調する必要があります。

そうは言っても、配管は過去に文書化されていましたか？

配管は、stdoutやstderrなどのストリームをリダイレクトすることによって機能します。 lesscに出力ファイル名が指定されていない場合は、stdoutに出力されます。 その意味で、配管は常に公式にサポートされており、引き続きサポートする必要があります。 そうでなければ、パイプに依存してジャストインタイムでコンパイルされたファイルをcssとして提供する必要のあるサーバーアプリケーションに通信する人々にとって、多くの正気のユースケースを破ることになるでしょう。

ソースマップと一緒にパイピングを使用したい場合でも、それはまともな方法で可能です。
インラインソースマップにしてから、パイプ内の追加の処理ステップに依存してインラインマップをデコードする必要があります。 変更をそれにマージします。 これらの手順でlesscコンパイラによってコンパイルされたCSSがさらに変更されるたびに、インラインソースマップとして再適用します。

次に、パフォーマンスのために外部ソースマップが必要な場合、つまり、インラインマップの追加バイトがすべての訪問者に配信されるのを回避します。 -パイプラインの最後のステップでは、インラインソースマップを解除し、cssファイルとマップファイルの2つのファイルを出力する必要があります。

外部ソースマップを生成してから、出力cssを別の操作にパイプすることは意味がありません。

パイピングは、チェーンの次のステップで発生するさらなる変更、または最終ステップでWebサーバーアプリケーションによって提供されるために消費されるCSS（およびソースマップ）を意味します。

私は引用された感情に同意しません、そして私は与えられたパイプの反対側にあるものを仮定することは間違っていると思います。 パイプがどこかにアップロードされている場合はどうなりますか？ パイプが結果のCSSを提供しているが、クライアントが常にソースマップを必要としない場合はどうなりますか？

--source-map-urlフラグが実装されていることを考えると、このユースケースはサポートされるべきだと思います。

いずれにせよ、特にヘルプテキストからフラグを渡すときに、ユーザーに不可解なキャッチされないエラーが表示されないようにする必要があります。

この問題によってブロックされた後、ちょうど私の2セント。