为什么在scss中把_放在文件名前面?

_filename。为什么它需要_ ?


当前回答

以下是文档的内容:

按照惯例,Sass文件只能作为模块[被导入]加载,而不能单独编译,以_开头(如_code.scss)。这些被称为部分文件,它们告诉Sass工具不要试图自行编译这些文件。你可以在导入partial时省略_。

另外,注意Sass部分不应该和@import一起使用,而应该和@use一起使用:

Sass团队不鼓励继续使用@import规则。Sass将在未来几年内逐步淘汰它,并最终将其完全从语言中移除。建议使用@use规则。(请注意,目前只有Dart Sass支持@use。其他实现的用户必须使用@import规则。)

这超出了最初问题的范围,但如果你好奇,原因如下:

The @import rule has a number of serious issues: @import makes all variables, mixins, and functions globally accessible. This makes it very difficult for people (or tools) to tell where anything is defined. Because everything’s global, libraries must prefix to all their members to avoid naming collisions. @extend rules are also global, which makes it difficult to predict which style rules will be extended. Each stylesheet is executed and its CSS emitted every time it’s @imported, which increases compilation time and produces bloated output. There was no way to define private members or placeholder selectors that were inaccessible to downstream stylesheets.

其他回答

此外,如果不使用下划线前缀,在节点环境中使用node-sass的监视器将导致错误消息,请参阅https://github.com/sass/node-sass/issues/2762

当你在文件名前包含“_”时,它不会生成到CSS中,除非你将它导入到另一个非局部的sass文件中。

假设您的文件夹结构是这样的

/scss
 style.scss
 _list.scss
/css

如果执行该命令

sass --watch scss:css

只会创建style.css和style.css.map文件,sass编译器会省略_list. map文件。而不需要将其内容转换为CSS文件。

/scss
 style.scss
 _list.scss
/css
 style.css
 style.css.map

使用partial的唯一方法是将它们导入另一个.scss文件

@import 'list.scss';

如果你移除_list前的“_”。SCSS命令的结果将是

/scss
 style.scss
 list.scss
/css
 style.css
 style.css.map
 list.css
 list.css.map

使用部分的主要目的是将我们的CSS代码分解成几个更容易维护的部分。希望这能有所帮助。谢谢。

_用于表示偏导数。这些部分包含预处理阶段所需的变量和内部函数,它们不需要被编译为css。_ partial templates包含utils, SCSS局部变量和编译SCSS到css所需的函数。

_(下划线)是scss的部分。这意味着样式表将被导入(@import)到主样式表,即styles.scss。使用部分的好处是,你可以使用许多文件来组织你的代码,所有的东西都将在一个文件中编译。

以下是文档的内容:

按照惯例,Sass文件只能作为模块[被导入]加载,而不能单独编译,以_开头(如_code.scss)。这些被称为部分文件,它们告诉Sass工具不要试图自行编译这些文件。你可以在导入partial时省略_。

另外,注意Sass部分不应该和@import一起使用,而应该和@use一起使用:

Sass团队不鼓励继续使用@import规则。Sass将在未来几年内逐步淘汰它,并最终将其完全从语言中移除。建议使用@use规则。(请注意,目前只有Dart Sass支持@use。其他实现的用户必须使用@import规则。)

这超出了最初问题的范围,但如果你好奇,原因如下:

The @import rule has a number of serious issues: @import makes all variables, mixins, and functions globally accessible. This makes it very difficult for people (or tools) to tell where anything is defined. Because everything’s global, libraries must prefix to all their members to avoid naming collisions. @extend rules are also global, which makes it difficult to predict which style rules will be extended. Each stylesheet is executed and its CSS emitted every time it’s @imported, which increases compilation time and produces bloated output. There was no way to define private members or placeholder selectors that were inaccessible to downstream stylesheets.