（ps:想直接看问题可以跳到转）
起🤨
故事发生在故事发生的那天。
依稀记得这天，阳光和煦，十月初下午的阳光慢慢收起了毒辣的目光，温和的注视着大地。仿佛看到了什么有意思的事情，悄悄将其一丝目光，投入窗中，照亮了小博的桌面，一切显得那么的岁月静好。
当然，如果没有把屏幕也照亮的话，一切就很完美了。😅
“***（懂得都懂），这**的太阳，公司就不能安个窗帘嘛，天天晃得我都看不清屏幕，就不能换个好点的显示器嘛？实在不行给我换个位置也行啊！😒 ”
本篇文章的主人公——小博，在如此美好的一天，心情却如此烦躁，实属不该。不过联想到其身份，没错，在这个论坛上，其身份各位也都应该猜的八九不离十，他就是一个——伟大的前端工程师。由此，其心情烦躁的原因各位也都应该能够理解了——上班的人哪有几个不疯的呢？🫠错过的阳光不会再来，打工人的咖啡还得自己付钱。小小的几句抱怨已经是打工人最大的修养体现……
殊不知更影响其心情的事情也已经到来。小博的抱怨声还没停止，有个同事就急匆匆的找了过来，"博哥，你给公司封装的代码规范工具有用户反馈有问题，你快来帮忙看一下！"边说着，边手法娴熟的拉了支持群，发来了视频会议邀请。
“shit!”小博暗暗骂了句，突然一道炸雷惊响，给小博吓了一跳，小博连忙接通了会议。
“你好，请问有什么问题呢？方便共享下屏幕复现下嘛？”
承😦
承接上文，先来介绍下这个所谓的代码规范工具——一个封装了eslint,stytlelint并会在pre-commit阶段（通过git hook实现）进行检查的一个工具，旨在尽可能早的暴露出部分编码问题，同时有助于实现代码风格的统一，便于项目组各成员能快速熟悉代码，也避免了安装上述格式化工具时遇到的种种问题，同时统一了规则。说了这么多，也不改其本质——一个良好的汇报材料，完美的kpi工具，谁叫之前公司没人做呢。😂
大致了解了这个工具，让我们把目光重新定位到小博这里，看看问题是什么，经过用户的演示，原来是stylelint扫描到了打包后的文件，这个文件位于dist目录下——一个已经在工具中被设置成默认的排除路径下。
“不可能啊，这是嘛情况？”小博喃喃的说道：“麻烦你看下仓库里安装的stylelint版本呢？” “13.13.1” "版本是正确的啊，难道这个版本stylelint nodeapi提供的参数有什么特殊的嘛？"小博心里暗暗想到，同时打开了stylelint的github地址，熟练地切换版本到13.13.1。
为什么要切换呢，因为目前stylelint的最新版本已经是16.x了，至于为什么工具要选择这个版本呢，因为stylelint 14版本往上就不会再自动推断你使用的语法了，需要用户手动指定，对于工具来说，当然是越简单越好，由此选择了这个版本。
查看了相关文档，小博并没有发现异常，同时，他意识到了一件事情，如果真有这个问题，也应该早就在之前测试中被发现了，会不会是这个项目有什么问题，想到这，他急忙点击用户头像，询问道：“其他人在这个项目下也有这个问题嘛？”
用户回复的很快：“稍等，我问问。”
小博耐心地等待着，忽然觉得屏幕没有那么刺眼了，抬头向窗外望去，原来厚厚的乌云早就盖住了太阳，形状怪异切位置极低，给人一种错觉，仿佛一抬手就能摸到，眼瞅着就要下雨了。
“他*的，这下班该怎么回家呢🙃？”小博心里吐槽，用户这时候也回复到：“他们这里都是正常的，难道是我电脑的问题？”
“有可能吧，我们之后再去排查下。”小博礼貌回复，心里暗戳戳松了口气，还好不是工具的问题。
“那我这个要怎么解决呢，现在提不上去代码了。”用户着急的问。
“可以先把工具生成的 hook 删掉呢。”小博回到，解决不了问题，就先解决有问题的人，可以在，这很程序员。
用户照做了后，也就没有在回复消息了，小博伸了个懒腰，以为一切尘埃落定，只是一个偶发的问题罢了，但本着程序员严谨的精神，又翻看 起用户发来的截图，以确认是否真的不是插件的问题。忽然，他注意到一个之前一直被忽略的地方，心头一震。
“难道，和这个有关，不会吧！😱”
转🫠
究竟是什么让小博如此惊讶呢，原来，用户保存项目位置含有中文，类似 “D:\项目...”这样。
之前小博从来没有注意到这一点，更别谈测试了。🤐
但还好，作为程序员的敏锐以及严谨让他没有放过这一丝可能性，于是，忙不迭的去模拟用户这种场景，新建文件夹，新建项目，新装插件，新……
终于，做好一切准备工作后，小博运行了插件。俨然看到，本该排除的打包目录下的文件，赫然存在在问题列表里。
“wtf?这中英文路径会影响stylelint?”小博心中一沉，匆忙打开github，去查找stylelint的issue，结果真的让他找到了相近的问题。(#5594),“看起来在windows下会有一些路径解析问题？”
小博还不敢妄下定论，于是只得翻看起stylelint相关代码，窗外的乌云愈发浓密，一滴雨不知何时落下，慢慢的连成一片，夹杂着雷声，构成一幅交响乐，却仍然惊扰不到小博，当程序员进入状态时，那么眼睛里就只有屏幕了。
经过了一段时间的排查，小博大致定位到了有问题的代码，如下图：
这个方法是在isPathIgnored.js文件中导出的，主要是用于判断路径是否在配置的忽略路径下。
问题就出在图中框选的内容里,小博先试了下正常的流程，可以看到，这里主要是使用slash将windows下的路径规范化。主要就是替换斜杠，之后使用microMatch进行匹配，如果匹配成功，则说明，当前路径符合排除路径，应该被忽略。
小博又试了下含有中文的路径，如下图：
很明显，含有中文的路径没有被正确的处理，也就不会被micromatch匹配，由此不会返回true，只会返回false，这也是bug的根因。
“啊这，这个slash方法是个啥，还会有这种问题？”秉着严谨，实则好奇加期待，认为自己又能给开源事业添砖加瓦的小博同学，去看了下这个slash库，只有一个文件，寥寥几行代码，如下：
简单说，通过正则做匹配替换，至于为什么中文不生效，因为当含有中文时，hasNonAscii这个值一直为true,于是便不会被处理直接返回源路径。
“有没有什么方法可以解决这个问题呢？”敏锐的小博同学又对代码一通调试，发现ignoreFiles在stylelint初始化时会有一个判断，具体代码如下：
可以看到，如果这个配置是已经处理好的绝对路径的话，就不会去转换，而是直接返回。
找到了解决方法，小博轻车熟路的快速在自己的插件中添加上转换路径的代码，之后经过多轮验证，完美解决了这个问题。😎
“搞定！”小博接着回复用户：“这个问题会在下次版本更新时修复，按照计划的话，预计是这个月的某一天。”
小博伸了个懒腰，不知何时雨也已经停了，仿佛它从未下过，夕阳展现了它绝美的容颜。
“该吃饭了！”
合🤓
俗话说，人是铁，饭是钢，一顿不吃饿的慌，小博急匆匆的赶去食堂干饭，然后好下班。路上遇到了之前的那位同事，“博哥，之前领导安排的任务要抓下进度了，刚刚领导问了。”
“fuck!”不用想，也知道是谁的心声。小博慢慢吃完了饭，回到了工位。
“哦，对了，看看能不能给提个pr修复stylelint这个问题。”小博想着，然后翻看了下stylelint的更新记录，发现在14版本就已经不再采用这个slash方法了。“看来是没有机会了。”小博遗憾地想着🫤，之后马不停蹄地又投入到紧张的工作中。
天色慢慢昏暗，暗到星星都消失不见。
于是，故事便结束在故事结束的那天。
