Less.js: data-uri関数は、のファイルへのパスを含む文字列ではなく、data-uri呼び出しのパスを使用します。

これが重大な変更（メジャーアップを保証する）なのか、バグ修正なのかについてのフィードバックを歓迎します。

参考：非常に簡単な方法で、下位互換性を損なうことなく、これをエレガントに実装できます。

現在、 data-uri()関数は、ファイルパスとして文字列を保持するQuotedツリーノードを受け入れ、関数呼び出しを保持するファイルの場所に対するURLとして内部的に解決します。 data-uri関数をオーバーロードして、実際のURLを保持するUrlツリーノードを受け入れることもできます。 このようにして、URLはurl() CSS関数が呼び出される場所に対して正規化され、 data-uri() Less関数の内部で正規化されなくなります。

例えば

// app/content/button.less
button {
  .background(url("images/btn.jpg"));
}

@rjgotten

私にとっては、修正というよりは回避策のように見えます。 さらに反復すると、 urlをミックスインに移動することで冗長性を回避しようとしますが、問題が再び発生します。 もう1つの問題は、この問題が発生した元のユースケース（＃2541）を使用すると、次のように使用されることが多いことです。

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

（例として、フォントと面のミックスインの場合、通常は複数のwoff 、 ttf 、 eot 、 eot?#iefixなどの拡張子が同じファイル名に追加されます。 ）。 そしてこのように、以前のurlも不可能です。

@ seven-phases-max

それなら、適切な解決期間があるとは思いません。 相対URLが解決されるコンテキストを決定する何らかの方法が必要です。 あなたはに入る文字列値定義されたファイルのファイル情報から、そのコンテキストを取るのいずれかdata-uri()機能を、またはあなたが経由して、カットオフ点をより明確にするurl()関数とUrlツリーノード。

パス変数の置換をサポートする場合は、パスのさまざまな部分を正規化する必要がある方法を理解する必要があるため、すぐに注意が必要になります。

たとえば、次のようなものをどのように正規化しますか。

// mixins.less
.background(@image) {
    background-image: data-uri("../../@{image}.jpg");
}
// app/content/button.less
button {
  .background("../images/btn");
}

相対URL解決と、これら2つのパスのトークン置換主導の組み合わせをどのように組み合わせますか？

代替トークンがurl()またはdata-uri()入る最終的なURL値の先頭にある場合、1つのオプションは、代替トークンの代わりに使用される文字列を定義するファイルに対してのみ解決することだと思います。

別の解決策は、パスを結合したり、ファイル拡張子を追加/削除/編集したりするためのパス処理関数をいくつか導入し（ unit()関数がディメンションに対してどのように機能するかと同様です）、物事をより明確にすることです。

例えば

// mixins.less
.background(@image) {
    background-image: data-uri(extension(<strong i="21">@image</strong>, "jpg"));
}
// app/content/button.less
button {
  .background(url("./images/btn"));
}

最初の例では、特別な正規化は必要ありません。 "../../@{image}.jpg"は、記述されたとおりに"../../../images/btn.jpg"展開されます（パスを処理するのに最大data-uriになります）。
そして2番目の例はただ...関数をスタックして関数を回避し、下位互換性を回避します...正確には何ですか？ 他のファイルで定義されたミックスインを呼び出すときの_間違った_ファイルパス？

結局のところ、 .background(url("images/btn.jpg"));で「期待どおり」に_only_動作することになっているとしたら、まったく変更を加えずに.background(data-uri("images/btn.jpg"));直接書き込むのとどう違うのでしょうか。 :)

言い換えれば、これを修正する場合は、どんなに壊れてもdata-uriで固定する必要があるということです。 （正直なところ、私はより良い戦略が何であるかわかりません：a。これについてのより多くのレポート/リクエストを待ってから（それらが十分にある場合）変更するか、b。起こり得る破壊的な影響を最小限に抑えるためにそれを早く変更します）。

_{言い換えると、 urlとdata-uriが最初は交換可能として設計されたと仮定します（つまり、 data-uriはurl特別なバージョンです（そしてCSS urlコンパイルされます）。最終的にdata-uriが「このように」動作するのに対し（そのようなオプションを使用）、正確にulrが「このように」動作する理由を説明するのは非常に困難です。このようなオプション）、および特定の動作を取得するためにあなたが必要がありますdata-uri(url()) 」に限定コンボ、 data-uriミックスイン内部とをurl _out_とそれの--relative-urls: on "<-Bhrrrr ... :)}

私にとっては、修正というよりは回避策のように見えます。 さらに反復すると、URLをミックスインに移動することで冗長性を回避しようとしますが、問題が再び発生します。

ええ、私は同意します。

私はゆっくりと、v3リリースのために少し努力を減らし、これを修正するように努力しています。

考えられるすべてのファイルパスを調べて、1つずつ試してみようと考えていましたが、異なる場所に複数のファイルがある場合は少し厄介です...これを永久に完全に修正することは不可能だと思いますが、少なくとも通常のケースを修正できます。

おそらくresolve()関数は、解決されたURLを関数に渡すのに役立つ可能性があります（ただし、完全なパスが機能しない場合は、これが修正されたときに完全なパスが機能します...）

すぐに考えを書き留めてすみません。

これは単なる簡単なメモですが、変数補間を使用したインポートでも同じ問題が発生します。

変数補間を使用してインポートします。

それは面白くて不安なことです。
それは実際にサポートされているユースケースですか、それとも幸せな偶然ですか？

@rjgottenサポートされていますが、サポートは多少制限されています。 ＃410で追跡されました

これは機能します：

<strong i="8">@variable</strong>: "path.less";
<strong i="9">@import</strong> "@{variable}";

これはしません：

.mixin(@variable) {
  <strong i="13">@import</strong> "@{variable}";
}

編集：リンクが機能するように変更されました。

ミックスインで変数@importをサポートしたいかどうかわかりません。
変数のインポート全体は少し魔法のようで、直感に反するコードを作成する可能性があります。

回避策についての多くの議論、多分実際の問題を修正するだけですか？ data-uriは処理中のファイルに関連している必要があることは明らかではありませんか。

現在、別のパスから_a reference_をインポートするファイルがありますが、それでもdata-uriについて文句を言います。 少なくともそれはバグであるに違いありませんか？ つまり、参照によってインポートする場合、現在のファイルを基準にしてパスを書き換えようとしないでください。

@Ciantic

つまり、参照によってインポートする場合、現在のファイルを基準にしてパスを書き換えようとしないでください。

正確には何に基づいていますか？ reference何の関係がありますか？

現在、別のパスから参照をインポートするファイルがありますが、それでもdata-uriについて文句を言います。

上記の問題とは逆のように聞こえます。 詳細を教えてください。 （たとえば、インポート、インポート、およびデータファイルのパスなど）。

styles.less

.something {
    background: data-uri("some.svg");
}

sub / test.less

<strong i="11">@import</strong> (reference) "../style.less";
.test {
    color: green;
}

これはstyle.lessをコンパイルしますが、test.lessと比較してdata-uriを使用しようとするため、test.lessはコンパイルしません。

なぜ参照インポートがパスを書き換えようとするのでしょうか。私の意見では、参照を使用する場合は必要ありません。

data-uriはオプションのURL書き換えルールに従うことを期待します。 もちろん....それがdata-uriで実際に何を意味するのかを言うのは難しいです。

一般に、data-uriは「.lessファイルの呼び出し」に関連して解決する必要があります。 したがって、ミックスインの場合は、ミックスインの場所ではなく、ミックスインが呼び出された場所を基準にして解決する必要があります。 ミックスインはそれらのステートメントを「ミックスイン」してから解決します。 だから@lukeapage私はあなたの解釈が正しいと思います：

// app/content/button.less
button {
  .background("images/btn.jpg");
}

app/content/images/でbtn.jpgを探す必要があります。 そうでない場合は、ミックスインがどのように機能するかではないため、これはバグです。 これは「重大な変更」ではなく、バグ修正だと思います。

そうは言っても...次のような解決に問題はないと思います。

1. 発信者に関連して解決しようとしています。
2. ミックスインに関連して解決しようとしています。

Node.jsは、解決のために複数のパスを試行します。 解決順序が明確に文書化されている限り、期待を管理できます。 そして、そのようにそれを行うことは、誰かが行動＃2を行うために彼らの.lessに基づいていた場合、それはすべてではないにしてもほとんどすべての場合でも機能することを意味します。

@ matthew-ディーン
一般に、data-uriは「.lessファイルの呼び出し」に関連して解決する必要があります。 したがって、ミックスインの場合は、ミックスインの場所ではなく、ミックスインが呼び出された場所を基準にして解決する必要があります。 ミックスインはそれらのステートメントを「ミックスイン」してから解決します。

すべてのユースケースで一般的に正しい方法でそれを機能させることはできませんでした。

たとえば、パラメータ化されたURL、つまり、置換トークンのみが入力された既知のベースフォルダに対して解決する必要がある置換トークンを含むURLをどのようにサポートしますか？ その場合、呼び出し元のファイルではなく、呼び出し先のファイルに対して再解決する必要があります。

コールサイトでurl()を明示的に使用せずに、これを透過的に修正する方法について少しひらめきがありました。それをミックスインコールにリファクタリングし、物事を壊します）：

リテラルQuotedノードが作成されるとき、それらのファイル情報を保持します。 変数の割り当て、ミックスイン呼び出しなどを介してその情報を伝達します。呼び出し元ファイルから発生したQuoted値は、 url()またはdata-uri()で処理されると、その呼び出し元ファイルに対して解決されます。 。 ただし、ミックスインの内部ロジックの一部であるQuoted値は、ミックスインのローカルファイルに対して解決されます。

これにより、次のような置換文字列を使用したシナリオを除いて、すべてが期待どおりに機能し続けます。

// mixins.less
.background(@image) {
    background-image: data-uri("@{image}.jpg");
}
// app/content/button.less
button {
  .background("images/btn");
}

それらを修正するために引っ張ることができるトリックもあります。置換トークンに入力するときに、トークンが置換文字列の最初にある場合、結果の文字列は、入力されたトークンからファイル情報を継承する必要があります。置換文字列の。

ミックスイン自身の作者の意図が、そのようなパスをミックスインファイルに対して解決することである場合でも、たとえば"./@{image}.jpg"をパターンとして使用することで、その作者はそれを機能させることができます。 それはあなたが望むものである発信者から責任の負担を効果的にシフトします。

// _mixins.less
.sprite(@image) {
    background: data-uri("../images/sprites/@{image}.png") no-repeat;
}

// main.less
div {
   .sprite('logo');
}

出力：

div {
   background: url(data:image/png;base64,...) no-repeat;
}

うわー、これは非常に古いものです....この問題が私にも影響を与えているので私の2セント。

URL関数にオプションを追加したり、URLを絶対として解決する新しい関数を作成したりするのはどうですか。 そうすれば、ミックスインがどこに設定されていても、絶対パスで動作し、間違いの余地はありません。

URL関数にオプションを追加したり、URLを絶対として解決する新しい関数を作成したりするのはどうですか。 そうすれば、ミックスインがどこに設定されていても、絶対パスで動作し、間違いの余地はありません。

ここでの問題は、絶対パスと相対パスに関するものではありませんでした。 それは、コールサイトに対する相対的なものと宣言サイトに対する相対的なものについてでした。 全く違う問題。

おそらく問題は進展しましたが、最初のコメントとタイトルは、呼び出されたファイルに関連するパスを解決するdata-uriに関するものであり、別の場所に配置されたミックスインと組み合わせると、パスが正しく解決されない可能性があります。 まあ、それは私が経験している問題です。

では、解決策として絶対パスはどこでそれを考慮に入れるのでしょうか？

data-uriが絶対パスを受け入れ、架空のabsolute-url関数があるとすると、ミックスインがどこに配置されていても、次のコードは機能します。

// mixins.less
.background(@image) {
    background-image: data-uri(@image);
}

// app/content/button.less
button {
  .background(absolute-url("images/btn.jpg"));
}

@ miljan-aleksic「絶対」とは、 data-uri場所にあるファイルに関連することを意味しますか？ もしそうなら、「絶対」はおそらく間違った用語です。

ただし、URLファイル相対を作成するためのURLの機能ラッパーのようですが、これは良いアプローチです。 または、url（）への追加の引数。

@ matthew-dean、絶対的にはファイルへのフルパスを意味します。例： /users/myuser/projects/lessproject/icon.svg 。

url（）が、ubicationを知らずに、data-uriロケーションファイルへの相対パスを作成する方法がわからないため、あなたのアプローチはわかりません。

ただし、URLファイル相対を作成するためのURLの機能ラッパーのようですが、これは良いアプローチです。 または、url（）への追加の引数。

おかしなことに; それは私が数年前に提案したこととほぼ同じです。 ;-)

絶対とは、ファイルへのフルパスを意味します（例：/users/myuser/projects/lessproject/icon.svg）。

絶対パスでは、 absolute-url関数が呼び出されるファイルの場所に基づいて、このabsolute-url関数が完全な出力パスに渡される相対パスを_pre-resolves_することを意味しているように見えます。コンパイルされた出力CSSファイルが移動する場所を基準にしています。

つまり、あなたは両方とも同じことを意味します。 私もそうだった、当時。

コンパイルされた出力CSSファイルが移動する場所を基準にして、absolute-url関数が呼び出されるファイルの場所に基づいて完全な出力パスに移動します。

のように、書き換えURLまたはルートパスは引き続き適用されますが、定義の場所に基づいていますか？ これは、 @ lukeapageの元の例とは少し異なるようです。この例では、出力に関連するURLについてではなく、_コンパイル中の_URLについて説明していました。 例： data-uri()場所。

したがって、人々が類似しているが完全に同一ではない問題について投稿しているため、この問題を追跡するのは少し難しいです。 つまり、相対的な_source_を変更するには、相対的な_output_を変更するのとはかなり異なるソリューションが必要になる可能性があります。 またはおそらくそうではありません。 パスロジックに依存します。 ただし、data-uriは出力としてパスを生成しないことを明確にする必要があります。

たぶんresolve()ようなものが必要ですか？ わからない、ただ唾を吐くだけなのにurl(resolve(file(), "my/path")) ？ @ miljan-aleksicがabsolute()意味するところだと思います。つまり、絶対URLに解決されます。 ただし、それでも入力が必要です（解決するにfile() 、 file-resolve()ようなことを実行して、そのロジックを1つの関数で指定できますが、 resolve()とfile()を2つの関数として持つと別々に役立つ場合があります。

これらすべてについて注意が必要なのは、すべての書き換えURLオプションです。これにより、PRマージの時点で、モジュールのサポートが追加されました。 （https://github.com/less/less.js/pull/3248）。 それで、ファイル相対URLを返す場合でも、それを書き換えることはできますか？ はいと思いますが、明確にする必要があります。

はい、resolve（）とfile（）は、私が説明しようとしていたことを正確に定義しています。 近い将来、これが実装されることを期待しています。

@ miljan-aleksicさて、それは理にかなっています。

実際、 file()は正しくありません。これは、私が推測するファイル名を返すため、 dir()ます。 そして、それはおそらくファイルごとの変数定数でなければなりません。

どうですか：

data-uri(resolve(<strong i="10">@DIR</strong>, "my/path"))

そのため、2つのことが追加されました。1）パスを結合するresolve（）関数、2）評価中に各ファイルに挿入される@DIR （および@FILE ？）定数。 それについての唯一のトリッキーなことは、それらの注入された変数がルート内の他の変数をオーバーライドまたはマージしないことをテストすることですが、それに対してテストするのはかなり簡単なはずです。 または、 @argumentsように小文字にする必要がありますか？ その場合、競合を避けるために@directoryと@filenameをお勧めします。 最も少ないyオプションは何ですか？

たぶんresolve()ようなものが必要ですか？

^ビンゴ。 まさにその通りです。

最も少ないyオプションは何ですか？

Node.js-yオプションを選択します： __dirname
それは長い間存在していて、よく知られています。 Lessの同じ概念に同じ名前を使用するのは良い考えかもしれません。

Node.js-yオプションを選択します：__ dirname

エラー...それはLess / CSSキーワードにもLess変数にも関数セマンティクスにも一致しません。 それよりもうまくやらなければならないでしょう。 @__dirnameかもしれませんが、アンダースコアはまだ言語にとって少し奇妙です。 それはまったく適合しません。

アンダースコアは、言語にとってまだ少し奇妙です。 それはまったく適合しません。

特に組み込み変数のようなものに関しては、多くの言語で「システムが提供するもの」を示すために、二重の先頭の下線が使用されます。 ですから、場違いはそこにあるポイントのようなものです。

もちろん; 気に入らない場合は、いつでも@dirnameや@dir-nameような派生物を使用できます。

しかし、これについてもう少し考えたのに、なぜ現在のファイルパスを変数として公開する必要があるのでしょうか。 概念的なresolve()関数自体に織り込むことはできませんか？

概念的なresolve（）関数自体に組み込むことはできませんか？

そして、関数名を変えるだけで、私の提案に戻りました。 私はまだそれが一番好きで、resolve（）としてさらに良いです。

そして、関数名を変えるだけで、私の提案に戻りました。

ある種。

私が得ているのは、 resolve()関数の呼び出しを保持しているファイルのURL /パスを渡す必要がないということです。その場所は、関数に対して_既知_である必要があるためです。

関数内のthisは、 currentFileInfoプロパティを持つFunctionCallerインスタンスをcurrentFileInfoます。
そのプロパティは、関数呼び出しに対応するCall ASTノードのファイル情報に初期化されます。
つまり

https://github.com/less/less.js/blob/4e903e8254cc20fec80fccd35794fb797949e653/lib/less/tree/call.js#L47

コードを正しく読んでいる場合、そこにあるファイル情報は、関数呼び出しが評価されるファイルではなく、関数呼び出しが_宣言されている場所のファイル情報に対応します。

つまり、このファイル情報を「熱心な」URLリゾルバーに使用しても問題ありません。 別のファイルのコンテキスト内でインポートおよび評価されるミックスイン内に関数呼び出しが配置された場合でも、期待どおりに動作します。 つまり、ミックスインが定義されているファイルに固定された解像度で。

しかし、これについてもう少し考えたのに、なぜ現在のファイルパスを変数として公開する必要があるのでしょうか。 概念的なresolve（）関数自体に組み込むことはできませんか？

現在のファイルや一般的なリゾルバー関数が必要ないことが確実な場合...多分...明示的なローカル変数は、それがジェネリック関数ではなく、関数が次のように評価されないことを明確にしますその他の機能。 それが私の本当の関心事です、セマンティクスです。 名前に関係なく、「現在のファイル」の特別な「マーカー」がない場合は、入力に基づいて同じように解決される他の関数とは異なります。 言い換えれば、それは目に見えない入力に従って解決する関数であり、それは私に関係しています。 ただし、関数がcurrent-file-resolve()ように非常に明示的なものである場合は、それで十分です。 そうしないと、ミックスインが定義されたファイルではなく、呼び出されたファイルに従ってミックスイン呼び出しがspecialfunction()解決しなかった理由を人々に混乱させることになります。

したがって、いいえ、ローカル変数は技術的には_必要_ではありませんが、意味/出力/動作はセマンティクスから明確である必要があります。

うーん...

OK。 次に、 resolve-url(url, [base])関数があります-オプションのbase ; デフォルトでは、関数呼び出しが書き込まれる/宣言される/定義されるファイルのディレクトリになります。 次に、作成者がパスを明示的にプルしたい場合に備えて、 this.fileInfoをプルしてパスを取得するdeclared-dir()関数を用意します。 別のファイルからパスを取得したい。 または、URL解決に関係のない他の機能の一部としてこれを使用する必要があります。

つまり、完全な形式の呼び出し（暗黙のベースなし）は次のようになります。

resolve-url("../foo", declared-dir())

...そしてただやることと同等だろう

resolve-url("../foo")

...これは怠惰なものと同等の熱心なものです

url("../foo")

そのように「自動的に」注入された変数は必要ありません。 これは、純粋にプラグイン関数のセットとして実装できると思います。 そして、必要な唯一のコアメカニズムは、URLを「解決済み」としてマークする方法です。これにより、デフォルトのリゾルバーロジックがresolve-url関数から出力されるURLで実行されないようにブロックできます。

セマンティクスは、もちろんドキュメントで明確にする必要があります。 そして、そのドキュメントは、 urlをresolve-urlと明示的に比較して、熱心で怠惰な評価/解決を説明することができます。

_{インポートされたファイルのスコープが同じであるため、「注入された変数」のアイデアが（追加のハックなしで）機能しない場合に備えて。}

<strong i="7">@__dir</strong>: "whatever";
// *everywhere* it's the only <strong i="8">@__dir</strong> value = the path of "c"
<strong i="9">@import</strong> "a";
<strong i="10">@import</strong> "b";
<strong i="11">@import</strong> "c";

関数ベースの実装について言えば、 this.context.?またはthis.context.frames[?]どこかで関数が呼び出されるファイルのパスを取得することはまだ可能だと思います（ただし、確実ではありません）。とか、ぐらい。

うーん、それで私たちはそれを解決するためのより良い方法がありませんか？

@heynext
うーん、それで私たちはそれを解決するためのより良い方法がありませんか？

遅延評価はこれを適切に解決することを非常に難しくします、私は恐れています。

@ seven-phases-max
関数ベースの実装について言えば、 this.context.?またはthis.context.frames[?]どこかで関数が呼び出されるファイルのパスを取得することはまだ可能だと思います（ただし、確実ではありません）。とか、ぐらい。

はい、その階層でCallノードを見つけることができるはずです。