吃一堑长一智系列：less

[soda-x]

同步一篇旧文，下文中的 Gravity 指的是浏览器的 Bundless 方案，可在 D2 分享 - 基于浏览器的实时构建探索之路 中找到相应的内容

之前犯了一个认知的错误，卡了很久，分享给大家.

在 webpack 中 less 文件可以通过 import 的方式引入三方样式文件，该样式文件可以是 npm 库中的文件(@import "~npm/a.css")，或者本地文件(@import "relative/to/a.less")。

这里我认知出错的地方是： 以为 less-loader 可以处理所有 import 的文件 （less-loader 本质是一个 附加了 webpack resolve 逻辑的 less plugin），即我原认为 less-loader 处理完之后是一个完全可用的 css 文件（事实不是如此）。

我的卡点就是： Gravity 中尝试实现 import npm 库发现，当我 @import "~npm/a.css" 时，less plugin 的 resolve 逻辑怎么都不会进入到我的自定义 resolve 逻辑中来（能注册成功插件，却不执行插件）。

恍然大悟的点是： 在 less 的设计中，不会对 css 文件做任何的处理，包括自定义插件，除非把 less 提供的 reference 强制把 css 设置为 less，即（@import (less) "~npm/a.css"），这种方式是强侵入性的，和 webpack 的方式相比需要我们感知更多的开发工具细节。 到目前我觉得 less 这一块设计是可以优化的，让插件开发者来决定是否走插件的逻辑，而不是现在的注册一个插件默认认定为是应用给 less 的，如果需要给该 css 应用 less 插件逻辑，得硬编码，这绝对不是面向用户的解决方式。 后来我发现，webpack 这一块处理是交给 css-loader 的， 即 less-loader 处理完 import less 逻辑后，其并不会处理 import css 逻辑，而 import css 逻辑交给了 css-loader 中的 postcss 去分析 import 的语法，再做进一步处理。

解决方案： 在 Gravity 中引入 postcss-loader

即实现链路 less-loader -> postcss-loader -> style-loader

[await-ovo]

sass 好像也是一样的，默认不会处理 @import 导入的 css， 都需要用 postcss-import 进一步处理~