398 - 《一个 Less 问题的排查过程》

一个问题的排查过程，绕了一圈，原来解法很简单。但一个收获是把 Less 的插件机制搞透了。

1、问题。

昨天用户遇到一个问题，使用 Mako 时遇到 Less 的使用问题。

目录结构如下。

+ bar
	- bar.less
	- zzz.css
- index.js
- index.less

代码如下。

// index.js
import './index.less';
// index.less
import './bar/bar.less';
// bar/bar.less
@import './zzz.css'

抛开 index.js，直接用 lessc 编译 less，执行 lessc index.less，得到结果如下。

@import './zzz.css';

less 编译后保留 css 的 import 是符合预期的，但是路径原样保留下来，回到 index.less 的编译结果时，他去找 ./zzz.css 就会从当前目录去找，而根目录不存在 zzz.css，然后就有问题了。

但是 webpack 是好的。

2、思路。

两个思路，1）排查为啥 webpack 是好的，Mako 的 less 插件是抄的 less-loader，理论上不应该存在差异，2）用我自己的思路去解，通过 less 的插件，加 visitor，找到 @import 语句的 ast 节点，用 enhanced-resolve 库去找下依赖，然后替换为绝对路径。

3、过程。

我先用自己的思路去解，跑通了，写了一个 less 插件如下，运行良好，用例也过了。（为了写 less 插件，还把 less 插件完整地重新过了一遍，花了 1 个多小时）

class CSSImportVisi