Haml: 機能リクエスト：フォルダのインポート

私はこれの有用性に懐疑的です。 関連するすべてのファイルを手動でリストする必要があることは、それほど面倒ではないと思います。 また、存在するはずのファイルが存在しない場合でも、実際のコンパイルエラーが発生しない危険性があるようです。 代わりに、スタイルは一見恣意的に消えます。

私はあなたの議論を理解しています、しかし、私はあなたがこれが必要とされる他のタイプの状況を見ているとは思わない。 現在、60以上のSassファイルを含むフォルダーがあります。 フォルダを@importする機能が

各ファイルを個別に含めることには多くの問題があります。 まず、ファイルを含めるのを忘れても、警告は表示されません。 次に、Sassに取り組んでいる開発者のチームがいる場合、フォルダーにファイルを作成した後、各開発者がファイルを手動でインポートすることを忘れないでください。 正しいことをする人によっては、最終的には壊れます。

また、フォルダのインポートは「良いこと」であることが優先されます。 Javaのimportステートメントを使用すると、パッケージ全体またはそれらのパッケージの特定のクラスをインポートできます。

同じ重みのセレクターはドキュメントの順序に従って解決されるため、一般的なケースではインポートの順序が重要です。 グロブとは、ファイルを追加すると、セレクターのグローバル解決順序が予期せず変更される可能性があることを意味します。

このような順序の問題はコードには存在せず、それらが存在する場所（rubyなど）にはそのような機能はありません。

sassコアのインポートメカニズムを変更せずにSassでこれを行う方法があるかどうかを確認したいと思います。 これにより、フレームワークとsassを使用する個人が、適切と思われる独自のグロブシステムを開発できるようになります。 例えば：

<strong i="8">@import</strong> file-list("foo/*.sass");

以前は@importに対して特別な解析ロジックがあり、これを排除していましたが、現在はありません。

真に動的なインポート（関数経由など）を許可する場合の問題は、ドキュメントの依存関係構造を動的に把握できなくなることです。 これは、キャッシングと選択的コンパイルの有用性が大幅に低下することを意味します。

順序付けの問題については、ファイルをアルファベット順に並べ替えたり、決定論的な（任意ではありますが）順序付けを行うことができます。 ただし、これには、ファイルの名前が変更された場合に順序が変更されて機能が中断される可能性があるという問題があります。

おそらく、グロブを介したそのようなアプローチは、そのような問題を防ぐためにネストされたセレクターを使用することを意味します。

私の意見では、ファイルのディレクトリツリー全体をインポートすることは、明示的なインポートアプローチよりもわずかな有用性しかなく、ユーザーに優先順位の問題を検討するように促します。 このような機能を追加する場合は、ディレクトリレベルだけでなく、より汎用的なものにしたいと思います。

最後に、依存関係グラフの外側にあり、sassエンジンへの単一のインポートとしてのみ表示されるglobを導入すると、globに一致する新しい依存関係が表示されたときにファイルを無効にすることが難しくなるということは正しいと思います。

フォルダをインポートすると、インポートされるファイルの順序があいまいになることに同意します。 ただし、それがユーザーにとって正しいかどうかを判断するのはユーザーの責任です。 状況によっては適合しますが、他の状況には適合しません。 フォルダの内容が同じ要素をターゲットにしないシステムを想像することは間違いなく可能です（私のものはターゲットにしません）。

特定のファイルのインポートが機能するのと同じように。 状況によっては適合しますが、他の状況には適合しません。

選択は開発者次第です。

ユーザーが順序に依存し、それを知らないスタイルシートを持つのは簡単すぎます。 何かがあったとしても、並べ替えが発生し、レイアウトのバグが発生して、追跡が非常に困難になる可能性があります。 そして、ディレクトリをインポートすることで誰かがそのような問題にさらされることになるということは十分に明確ではありません。 ただし、ファイル名で注文することは、これに対する十分な解決策になる可能性があるため、深刻な障害にはなりません。

私が考える拡張機能は、標準のファイルグロブを許可することです-おそらくDir.globサポートされているものです。 これはコンパイル時に解決可能であり、妥当な程度のパワーを提供します。

しかし、私はまだユーティリティについて確信を持っていない方法です。

Dir.globを介した順序付けはファイルシステムに依存し、プラットフォーム間で変わる可能性があることを考慮することが重要です。実際、MacとLinuxのこの違いに悩まされてきました。 したがって、そのような機能を実装することになった場合は、十分に文書化された簡単に理解できるアプローチに従ってリストを並べ替えることが重要です（例：小文字の並べ替え）

私もまだこの機能に少し傾いています。 コンパスが使用するインポートアプローチは、実際にはメンテナンスの負担ではありませんでした。 ただし、これは確かに一般的に要求される機能です。 メーリングリストやツイッターで4、5回くらい取り上げられていると思います。

確かに、何らかの方法でファイルを決定論的に順序付けます。 アップケースとダウンケースの並べ替えは興味深い質問です...タイブレーカーとしてアップケースを使用してダウンケースを実行する必要があります（大文字と小文字が区別されるファイルシステムでのタイが可能になるため）。

同意します。 パラメータをDir.globに直接渡すことができないのはちょっと反対です。 それは本当に不要な機能のようです。 あなたたちは、その程度の制御を持つことが有利であるシナリオを思い付くことができますか？

次の2つのオプションで十分なようです。
-@ importを使用したチェリーピックファイル
- @ importfolder_nameを使用してディレクトリ全体をインポートします

また、アルファベット順でも問題なく動作すると思います。 文書化されていることを確認する必要があります。

<strong i="5">@import</strong> dirを介してディレクトリをインポートすることは、個々のファイルをインポートすることではあいまいすぎます。 少なくとも*グロブを確実に追加する必要があります。

しかし、まだ納得していません。

ページにさまざまな「スタイル」がある場合に便利です。 例：
generic /（xx sassファイルはこちら）
style1 /（ここでは、一般的なスタイルにスタイルを追加/上書きするxx sassファイル）
style2 /（ここでは、一般的なスタイルにスタイルを追加/上書きするxx sassファイル）
style1.sass（単に：@importジェネリック/ _、STYLE1 / _）
style2.sass（単に：@importジェネリック/ _、スタイル2 / _）

ジェネリックディレクトリ内のすべてをインポートする_generic.sassがないのはなぜですか？

私はそれが彼らがしなければならないほど多くのことができるかできないかについてではないと思います。 最終的にはスタイルシートの順序が重要なので、ユーザーに考えてもらいたいと思います。 ミックスインと変数のみを定義するライブラリは、スコープ付きスタイルシートと同様に順序に依存しないことは事実ですが、誤用

「スコープスタイルシート」を定義しますか？

ほとんどまたはすべてのセレクターをネストするスタイルシート。 例： body.foo

これらは、順序に依存しないことが保証されているわけではありません。 他の場所にある別のスタイルシートは、 body.foo ... 、またはより高い特異性を持つ他の何かを定義することができます。

次に、ファイルが正しく分離されていないため、実際には機能するフレームワークがありません。

人々がCSSを台無しにする方法はたくさんあります。 このソリューションを提供し、個々のファイルのインポートでいつ使用する必要があるかを説明できます。

この機能を実装しないことにより、これを実行したい開発者にスコープ付きスタイルシートを実装するための次の2つの選択肢が与えられます。
1）各ファイルを個別に手動でインポートします（ファイルを見逃したときに通知されないため、独自のエラーが発生する可能性があります）
2）これらのファイルを動的に追加するビルドシステムを実装します（同じことを実装する人が複数いるため、これは無駄です）

スコープ付きスタイルシートのすべての順序依存性が、関心の分離が不十分な結果であるとは限りません。 検討：

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

このスタイルシートは十分に分離されていますが、それでも順序に依存します。

いずれにせよ、この機能を使用するすべての人がリスクを理解することを期待できるという考えは間違っています。 スタイルシートがインポートされる順序を全員が確実に理解できるようにする唯一の方法は、スタイルシートを明示的に指定することです。

概して、スコープのあるスタイルシートは順序に依存しませんが、懸念事項が正しく分離されている場合でも順序が重要になる場合があります。

見つからないインポートをサイレントに無視することは、sass3ではもはや問題ではありません。 cssインポートのみがサイレントに無視されます。

他の約60個をインポートするsassファイルが1つあります。 ファイルが追加または削除されたときに変更します。変更するときは常に順序を考えます。 それは私にとって負担のようには思えませんでしたが、むしろ必要なステップです。

インポートが見つからない場合（インポートには常に.sassを指定します）、テストは失敗します。

追加があります：可能な限り単純で、単純ではありません。

私の直感によると、これは物事を単純にしすぎて、1回のデバッグセッションですべての時間の節約が失われます。 とりあえずこれは取っておきます。 誰かがこの機能を提供するsassプラグインを作りたいのなら、私はそれらのユーザーのためにそれがどのように機能するかを見たいと思っています。

リチャードのポイントは、パーシャルが作成されてもエラーは発生しないが、インポートは追加されないということだったと思います。 これは、未使用のパーシャルを探して警告を出力することで軽減できると思います。

先に進んでこれを閉じます。

ああ、これは最悪だ...私は私のrailsアプリのアセットにpage_specific /というフォルダーを持っています...
これらはすべて大きなアセットブロブにコンパイルする必要があり、それぞれが完全にラップされています
body＃page1 {}、body＃page2 {}など..

それらが順序に依存する可能性はゼロであり、率直に言って、この全体が「見逃してしまいます-それを使用してください！いいえ!!!!!!」 がらくたは侮辱的です。

この機能のユーザーが順序が重要であることに気付いた場合は、ファイルを明示的な順序でインポートするか、スタイルをリファクタリングして順序に依存しないようにすることができます...この不足している機能を手動で回避するように強制するのは父性的なゴミです>： （（

確かに、この注文の小さな問題を最小限に抑える方法を考えることができます。 決定論的な順序付けが始まりです。 これを@ import-dirと呼び、潜在的な順序の問題のドキュメントも役立ちます。 railsはすでにrequire_treeを提供しており、そこにあるものは正常に機能しているようです。 唯一の例外は、ファイルが個別にコンパイルされるため、ミックスインと変数がフロアにドロップされることです。 ミックスインは明示的に順序に依存しないものとして配置された部分であることに注意してください。それでは、他のすべての人に機能するのに、なぜこれがsassに機能しないのでしょうか。

https://github.com/chriseppstein/sass-globbing

@chriseppstein素晴らしい！ （そしてマニアックなみんなのように怒鳴ってすみません）