从 Nuxt.js 与 PhpStorm 中的节点模块解析 SCSS 中的 @import .css

Posted 2023-02-22

【中文标题】从 Nuxt.js 与 PhpStorm 中的节点模块解析 SCSS 中的 @import .css

【英文标题】：Resolving @import .css in SCSS from node modules in Nuxt.js vs PhpStorm

【发布时间】：2020-12-09 17:04:57

【问题描述】：

假设我想从我的主要app.scss 中的节点模块导入一些样式表：

@import '~bootstrap/scss/bootstrap';

这将由 phpStorm 正确解决，并由 Nuxt.js 构建，一切都很好。

现在，如果我想对 a scoped node module（名称格式为 @scope/module 的节点模块）做同样的事情，Nuxt.js 和 PhpStorm 会出现分歧：

@import '@fortawesome/fontawesome-svg-core/styles.css';

这在 Nuxt.js 中运行良好，构建继续没有问题，但 PhpStorm 强调整个事情说 Cannot resolve directory '@fortawesome'

@import '~@fortawesome/fontawesome-svg-core/styles.css';

这被 PhpStorm 理解并且可以很好地解决，但是会导致 Nuxt.js 构建失败：

ERROR in ./client/assets/sass/app.scss
Module build failed (from ./node_modules/extract-css-chunks-webpack-plugin/dist/loader.js):
ModuleBuildError: Module build failed (from ./node_modules/postcss-loader/src/index.js):
Error: Can't resolve '~@fortawesome/fontawesome-svg-core/styles.css'

所以我的问题是：哪种语法会被认为是正确的，是否可以同时让 PhpStorm 和 Nuxt.js 满意？

对我来说，~@ 似乎更有意义，因为~ 解析为我的node_modules 的路径，并且其中的实际文件夹名称以@ 开头。与非作用域节点模块相比，仅使用 @ 会破坏这种模式，根据 PhpStorm 和 Nuxt.js 都需要 ~ 前缀。

【参考方案1】：

原来，问题是由.css 扩展引起的。

这适用于 PhpStorm 和 Nuxt.js： @import '~@fortawesome/fontawesome-svg-core/styles';

显然（根据this answer 和/或this issue）当.css 扩展名用于@import 语句时，sass-loader 不会真正导入给定文件，而是将其转换为@987654328 @ 语句，这确实是错误的，因为url() 无法正确解析~。

所以毕竟这两条略有不同的 SASS 行之间存在显着差异：

@import '@fortawesome/fontawesome-svg-core/styles.css';

这会导致@import url('@fortawesome/fontawesome-svg-core/styles.css')，这取决于 webpack 在构建过程中稍后解决。或者如果没有被 webpack 解析，它可能会被发送到浏览器，它肯定会失败。

@import '~@fortawesome/fontawesome-svg-core/styles';

这由sass-loader 解决，node_modules/@fortawesome/fontawesome-svg-core/styles.css 被导入到主样式文件中，在构建过程中（或在浏览器中）没有任何东西需要解决。

---

PS：我也意识到它与给定的节点模块是否被限定无关。这一切都归结为导入.scss 与.css。

【讨论】：

显然 Nuxt.js 在这两种情况下都将给定的styles.css 文件作为内联文件包含在最终的app.*.css 文件中。我的假设是，在第一种情况下，@import '@fortawesome/fontawesome-svg-core/styles.css'; 导致@import url('@fortawesome/fontawesome-svg-core/styles.css') 在某些时候被 webpack 内联，所以两者都从构建的角度工作，但它似乎更像是sass-loader 修复后的另一个加载器或机制搞砸了@import url() 部分，所以第二个似乎仍然是更清洁的解决方案。但这些只是假设。纠正我，如果我错了！