为什么编译器用于sass文件，而它们可以通过终端运行

Question

任何人都可以帮忙解释一下吗？我是Sass的新手。但是我不明白为什么人们可以在通过终端运行时使用编译器来编写sass文件。

Answer 1

在我学习SASS的时候，我实际上有同样的问题。

我一直想知道为什么大多数教程都涉及使用GRUNT / GULP或某种任务运行器，当有sass专有命令时，甚至用以下命令实时监视文件：

sass --watch app/sass:public/stylesheets

我将在question（没有人回答）中引用自己，只是为了分享我在SASS编译方面的经验：

  

Grunt ：使用grunt-contrib-sass - 一切顺利;我没有特别的理由选择了这个而不是grunt-sass，但我读到后者使用的libsass（c ++）比传统的ruby Sass更快。

     

Gulp ：使用gulp：sass - 我经常在观看时遇到错误   文件，它没有找到一些部分，但如果你再次保存，   一切都很好（这是在他们的共同问题中解决的 - 这个   虽然解决方案对我不起作用，但它也不会产生麻烦   默认情况下，您必须在顶部使用gulp-sourcemaps。

     

直接从控制台：没有任务运行者 - 到目前为止工作正常，生成   源图，并让您知道哪里有错误，就像使用   Grunt和Gulp。

因此，在使用SASS处理不同的项目后，我会说原因是：

• 教程在早期使用SASS时普及了任务运行器的使用
• 在一个项目中，你很少单独使用SASS，你很可能想要运行其他任务，所以将SASS任务添加到流程中是有意义的，这样可以节省时间并且有意义。
• 运行一个简单的命令（例如gulp sass或gulp）来运行默认的gulp任务（应包括sass任务）比记住一个必须放置的长命令更容易一遍又一遍的路径。

过了一段时间，我意识到您可以在package.json中使用NPM脚本来运行SASS命令行工具，如下所示：

"scripts": {
    "sass": "sass --watch app/sass:public/stylesheets --style compressed"
  },

然后从命令行运行它：npm run sass

以上不需要配置，您不必记住整个命令。

总而言之，在没有其他编译器/任务选手的情况下使用CMD SASS没有任何问题，只需使用您认为最舒服的任何内容。