Haml: 功能请求：导入文件夹

我怀疑这个的效用。 我认为不必手动列出所有相关文件真的很麻烦。 此外，当您期望存在的文件不存在时，它似乎可能会导致无法获得实际编译错误的危险。 相反，样式似乎是任意消失的。

我理解你的论点，但是，我认为你没有看到需要的其他类型的情况。 目前我有一个包含 60 多个 Sass 文件的文件夹。 如果无法@import文件夹，我需要维护一个单独导入每个文件的文件。

单独包含每个文件有很多问题。 首先，如果您忘记包含文件，则不会收到警告。 接下来，如果您有一组开发人员在使用 Sass，他们每个人都需要记住在文件夹中创建文件后手动导入文件。 依靠人做正确的事情最终会破裂。

此外，我们认为导入文件夹是一件“好事”。 Java 的 import 语句允许您导入整个包或这些包的特定类。

在一般情况下，导入的顺序很重要，因为相同权重的选择器根据文档顺序进行解析。 Globbing 意味着添加文件可能会意外更改选择器的全局解析顺序。

代码中不存在此类排序问题，并且它们所在的位置（如 ruby​​）没有此类功能。

我很想知道是否有办法在 Sass 中做到这一点，而无需更改 sass 核心导入机制。 这将允许框架和个人使用 sass 开发他们自己认为合适的通配系统。 例如：

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

我们曾经对@import有特殊的解析逻辑，这会排除这种情况，但现在我们不再这样做了。

允许真正动态导入（例如通过函数）的问题在于，文档的依赖结构变得不可能动态地确定。 这意味着缓存和选择性编译变得不那么有用了。

对于排序问题，我们总是可以按字母顺序对文件进行排序，或者提出确定性（尽管是任意的）排序。 不过，这仍然存在这样的问题，即如果文件名发生变化，排序可能会改变并破坏功能。

据推测，这种通过 globbing 的方法意味着使用嵌套选择器来防止此类问题。

在我看来，与显式导入方法相比，导入整个文件目录树的效用很小，并鼓励用户考虑优先级问题。 如果我们确实添加了这样的功能，我希望它具有更通用的用途，而不仅仅是在目录级别。

最后，我认为你是正确的，引入一个在依赖关系图之外的 glob 并且仅作为对 sass 引擎的单个导入出现意味着当出现与 glob 匹配的新依赖项时更难使文件无效。

我同意导入文件夹会导致导入文件的顺序不明确。 但是，这应该由用户决定是否适合他们。 它适合某些情况，但不适合其他情况。 绝对有可能设想一个系统，其中文件夹的内容不针对相同的元素（我的没有）。

就像导入特定文件一样。 它适合某些情况，但不适合其他情况。

选择应该由开发人员决定。

对于用户来说，拥有依赖于排序的样式表而不知道它太容易了。 任何事情都可能触发重新排序并产生难以追踪的布局错误。 而且还不够清楚，导入目录会让某人对此类问题持开放态度。 不过，通过文件名订购可能是一个足够好的解决方案，所以这不是一个严重的障碍。

我考虑的扩展将允许标准文件全局 - 可能是Dir.glob支持的那些。 这将在编译时解决，并提供合理程度的能力。

不过，我仍然对效用深信不疑。

重要的是要考虑通过Dir.glob排序取决于文件系统，并且可能会跨平台更改——我实际上已经被 Mac 和 Linux 之间的这种差异所困扰。 因此，如果我们最终实现了这样的功能，那么根据有据可查且易于理解的方法（例如向下排序）对列表进行排序对我们来说很重要

我也仍然有点反对这个功能。 指南针使用的导入方法并不是真正的维护负担。 但是，这肯定是一个普遍要求的功能。 我认为它现在已经在邮件列表和 Twitter 上提出了大约 4 到 5 次。

我们肯定会以某种方式确定性地对文件进行排序。 Upcased vs. downcased sort 是一个有趣的问题......我们可能应该使用 upcased 作为决胜局（因为它允许区分大小写的文件系统）。

我同意。 我有点反对能够将参数直接传递给 Dir.glob。 这确实看起来像是一个不必要的功能。 你们能想出一个场景，拥有这种程度的控制是有利的吗？

似乎以下两个选项就足够了：
- 使用@import 挑选文件
- 使用@import folder_name 导入整个目录

另外，我认为按字母顺序排列会很好。 我们只需要确保其记录在案。

通过<strong i="5">@import</strong> dir导入目录对于导入单个文件过于模糊。 我们绝对应该至少添加* glob。

不过还是不相信。

如果页面有不同的“样式”，这很有用。 例子：
通用/（这里有 xx sass 文件）
style1/（这里有 xx 个 sass 文件，它们在通用文件中添加/覆盖样式）
style2/（这里是 xx sass 文件，它们在通用文件中添加/覆盖样式）
style1.sass（简单地说： @import generic/_, style1/_）
style2.sass（简单地说： @import generic/_, style2/_）

为什么你不能让 _generic.sass 导入通用目录中的所有内容？

我不认为这是关于什么可以做或不可以做的事情，因为他们应该这样做。 最终样式表的排序很重要，所以我希望用户能够考虑到这一点。 确实，仅定义 mixin 和变量的库与作用域样式表一样与顺序无关——但我担心提供会被误用的通用功能。

定义“范围样式表”？

嵌套大部分或所有选择器的样式表。 例如body.foo

这些不能保证与订单无关。 其他地方的另一个样式表可以定义body.foo ... ，或者其他具有更高特异性的样式。

那么你真的没有一个工作框架，因为你的文件没有正确分离。

人们有很多方法可以搞砸他们的 CSS。 我们可以为他们提供这个解决方案，并解释何时应该使用它而不是导入单个文件。

通过不实现此功能，您为想要执行此操作的开发人员提供了以下两种选择：
1）手动导入独立每个文件（这可能会导致错误的它自己的，因为它没有告诉你，当你错过了一个文件）
2）实现一个构建系统来动态添加这些文件（这是一种浪费，因为会有多个人在实现同一件事）

范围样式表的所有顺序相关性肯定不是由于关注点分离不佳造成的。 考虑：

body.foo .baz {
  color: blue; }

body.bar .baz {
  color: red; }

这个样式表是分开的，但仍然依赖于顺序。

无论如何，我们可以期望使用此功能的每个人都了解风险的想法是错误的。 确保每个人都了解他们的样式表将按什么顺序导入的唯一方法是明确指定它。

总的来说，范围内的样式表与顺序无关，但即使关注点被正确分离，顺序也可能很重要。

静默忽略未找到的导入在 sass3 中不再是问题。 只有 css 导入会被默默地忽略。

我有一个 sass 文件，可以导入大约 60 个其他文件。 我会在添加或删除文件时更改它，并且在我这样做时总是考虑顺序。 对我来说，这从来都不是负担，而是必要的一步。

如果找不到我的导入（我总是为导入指定 .sass），那么我的测试就会失败。

有一个附加条件：尽可能简单，没有更简单。

我的直觉告诉我，这让事情变得太简单了，一次调试会话浪费了所有的时间。 我投票决定暂时搁置这件事。 如果有人想制作一个提供此功能的 sass 插件，我将非常有兴趣了解它对这些用户的效果。

我认为理查德的观点是，创建部分但没有为其添加导入时没有错误。 我想这可以通过寻找未使用的部分并为它们打印警告来缓解。

我将继续并关闭它。

哎呀，这太糟糕了......我在我的 rails 应用程序的资产中有一个名为 page_specific/ 的文件夹......
这些都应该被编译到大资产 blob 中，并且它们每个都完全包裹在
body#page1 {}、body#page2 {} 等...

它们依赖订单的可能性为零，坦率地说，这整个“你会错过 - 使用它！不！！！！！！” 废话是侮辱。

如果此功能的用户发现顺序很重要，他们可以直接以明确的顺序导入文件，或者将样式重构为不依赖于顺序......强迫每个人手动解决这个缺失的功能是家长式的垃圾>： (

我们当然可以想出一种方法来最小化这个排序的小问题。 确定性排序是一个开始。 称其为@import-dir，潜在订购问题的文档也会有所帮助。 rails 已经提供了 require_tree，那里的东西似乎工作正常。 唯一的例外是文件被单独编译，这会将我的混合和变量放在地板上。 我注意到 mixin 是被定位为明确与顺序无关的一部分，那么当它适用于其他所有人时，为什么这不适用于 sass 呢？

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

@chriseppstein太棒了！ （对不起，大家都像个疯子一样咆哮）