背景
有次排查bug无意间发现同事直接通过css module处理过后的类名修改样式。
如下类名
.index_settingPrivacyPage_3oJLv {
}
便告知同事，这种类名是不可靠的，如果类名hash依赖的内容被修改，hash就会改变，类名也会跟着变，写的样式就失效了。
同事回已经试过很多遍了，类名并没有改变，详细追问之下，同事是通过修改类中的样式增加、修改、删除，观察到类名的hash并未改变。
我也亲自尝试修改类中的样式或者修改类所在的dom，发现类名依旧没有发生改变。
也对css module类型生成规则愈发好奇。
网上查资料
这篇文章认为是将类名进行hash，仔细想想如果对类名进行hash，那么两个相同的类名必然生成相同的hash，并不能解决类名冲突的问题。
在google上对css module hash生成规则查找了一些资料，均未解决疑惑。
于是决定查看源码。
查看源码
css module是在webpack的css-loader中开启的，css-loader的配置信息
config.module
.rule('css')
.test(/\.css$/)
.set('sideEffects', true)
.when(options.cssModules, function (rule) {
rule.oneOf('module')
.resourceQuery(/module/)
.use('style')
.loader(r('style-loader'))
.end()
.use('css')
.loader(r('css-loader'))
.options(__assign(__assign({}, cssOptions), { importLoaders: 1 }))
.end()
.use('postcss')
.loader(r('postcss-loader'))
.options({ sourceMap: sourceMap, postcssOptions: postcssOptions })
.end()
.end();
})
var cssOptions = __assign(__assign({}, cssOptionsNormal), { modules: {
localIdentName: '[name]_[local]_[hash:base64:5]',
localIdentContext: srcContext
} });
var srcContext = path_1.default.join(context, 'src');
[name][local][hash:base64:5]，这个配置可以解释为何base64的hash有5位。
在webpack配置中并未发现太多有效信息。
只好去css-loader源码中探究。
经过debug将hash生成规则定位到src/utils.js文件中的defaultGetLocalIdent函数。
(这里有个插曲，webpack使用的css-loader是5.2.0版本，下载的源码是css-loader的master分支，有较大的差异，后面将源码切换为5.2.0debug中的代码才与源码的结构比较一致，这里走了点弯路。)
function defaultGetLocalIdent(
loaderContext,
localIdentName,
localName,
options
) {
let relativeMatchResource = "";
// eslint-disable-next-line no-underscore-dangle
if (loaderContext._module && loaderContext._module.matchResource) {
relativeMatchResource = `${normalizePath(
// eslint-disable-next-line no-underscore-dangle
path.relative(options.context, loaderContext._module.matchResource)
)}\x00`;
}
const relativeResourcePath = normalizePath(
path.relative(options.context, loaderContext.resourcePath)
);
// eslint-disable-next-line no-param-reassign
options.content = `${options.hashPrefix}${relativeMatchResource}${relativeResourcePath}\x00${localName}`;
return interpolateName(loaderContext, localIdentName, options);
}
最后返回了interpolateName函数执行后的结果。此函数是位于loader-utils库中的lib/interpolateName.js文件中。下面是该文件function interpolateName(loaderContext, name, options)中的一段代码也是生成css module类名hash的核心算法
if (content) {
// Match hash template
url = url
// `hash` and `contenthash` are same in `loader-utils` context
// let's keep `hash` for backward compatibility
.replace(
/\[(?:([^:\]]+):)?(?:hash|contenthash)(?::([a-z]+\d*))?(?::(\d+))?\]/gi,
(all, hashType, digestType, maxLength) =>
getHashDigest(content, hashType, digestType, parseInt(maxLength, 10))
)
.replace(/\[emoji(?::(\d+))?\]/gi, (all, length) =>
encodeStringToEmoji(content, parseInt(length, 10))
);
}
可以发现调用了下面的函数，获取hash值
getHashDigest(content, hashType, digestType, parseInt(maxLength, 10))
通过debug来观察入参都传了些什么，
入参的content有vue文件的路径和类名组成，加密方式是base64，这也就解释了为什么改变类中的样式或者改变dom最终生成的类名并未改变了。
得出结论
通过上面源码分析得出的结论是 css module类名中的hash是由路径和类名构成
验证结论
以comment-title 为例
.comment-title {
height: 26px;
font-size: 18px;
font-weight: 500;
color: #111111;
line-height: 26px;
margin-left: 16px;
margin-right: 16px;
}
其被应用到的vue文件名为
这个类名被编译后的类名是
现在我们修改其被应用的vue文件名
最终编译后的类名变为了
可以发现发生了变化，也验证了上面的结论，破案！
