Less.js: ソースマップセレクターの行番号が間違っています-chromeは、最後の要素ではなく、最初の要素の位置を報告します

これは、セレクターのさまざまな場所からのさまざまな部分を実際にマークアップすることが少ないためだと思います。したがって、セレクターの最初の部分は3行目から、2番目の部分は9行目からのものであることがChromeに通知されます。lessが&使用する場合

ただし、クロムの情報はとにかく非常に大雑把なので、セレクターの最後の部分からの情報のみを表示する必要があります。

このバグは現在、クロムのバグに含まれています： //code.google.com/p/chromium/issues/detail？id = 287382

自己メモ：各パスが出力される前にfileinfoをオーバーライドすることで解決できます。 また、中央のセレクターが置き換えられる拡張についても考慮する必要があります。拡張のためにパスが作成されるため、拡張が重要です。

いつでも下にスクロールできるので、これを今のところ低くマークします。少なくともポインタが表示されます。 @ dotnetwiseが大きな問題を引き起こしている理由がない限り、

注：＃1715からの回避策は、セレクターではなくプロパティを制御してクリックすることです。
注2：chromeはそれを修正しないので、おそらく最後の要素インデックスを見つけるために、より少なく対処する必要がありますか？ セレクターで

私は次のサンプルコードをテストしました： http ：

#main {
max-width: 500px;
color: white;
.sub-container {
color: blue;
}
}

問題はクロムだけでなくFirefoxでも発生することがわかりました。 次に、gulp-lessとgulp-sourcemapを使用してコードをコンパイルしようとしました（gulp-sourcemapが別のソースマップジェネレーターを使用することを期待しています）。 gulpビルドでも問題は解決しませんでした。
同じコードをsassでコンパイルすると、生成されたソースマップはchromeとFFの両方で4を正しく指します。

一方、Lessは、ある時点で正しい行番号を持っています（--line-numbers = commentsを使用）。

/* line 1, /t.less */
#main {
  max-width: 500px;
  color: white;
}
/* line 4, /t.less */
#main .sub-container {
  color: blue;
}

はい。ただし、「ネストされたルール」ではありません。

大きなルールで何かをネストすると、すべてのソースマップ行がその上部を指します。