LightningCSS 中 CSS Modules 纯模式检查的演进与思考

纯模式检查的起源与争议

LightningCSS 作为现代 CSS 处理工具，在 CSS Modules 实现中引入了纯模式（pure mode）检查功能。这一功能要求所有样式选择器必须显式声明为局部或全局作用域，否则会报错。这一设计初衷是为了强制开发者明确样式的作用范围，避免样式污染问题。

然而在实际应用中，特别是在大型项目迁移过程中，开发者发现需要为某些特殊情况（如第三方组件样式）提供豁免机制。这引发了关于 LightningCSS 是否应该承担样式检查职责的讨论。

技术实现方案

针对这一需求，社区提出了类似 TypeScript 中 @ts-ignore 的豁免注释方案。具体实现是在 CSS 文件顶部添加特殊注释：

/** cssmodules-pure-no-check */
:global(#stripe-modal-backdrop) {
  background: rgba(0, 0, 0, 0.5);
}

这种方案的优势在于：

1. 细粒度控制：可以针对单个文件进行豁免
2. 显式声明：开发者必须主动添加注释，避免滥用
3. 向后兼容：不影响现有纯模式检查的全局配置

框架集成带来的挑战

现代前端框架（如 Next.js）往往将 LightningCSS 作为内置工具链的一部分，并默认启用纯模式检查。这导致开发者无法通过配置关闭检查，只能通过修改框架核心代码或等待框架更新。这种情况凸显了工具链设计中的一个重要考量：核心工具应该提供灵活性，而框架集成层可以做出更严格的默认选择。

工具定位的思考

LightningCSS 维护者提出了一个值得深思的观点：CSS 处理工具是否应该承担样式检查的职责？从架构角度看：

• 支持检查的观点：样式作用域明确化是 CSS Modules 的核心价值，工具应该强制保证
• 反对检查的观点：样式检查属于 linting 范畴，应该由专门工具（如 stylelint）处理

这种边界划分的讨论反映了现代前端工具链的演进趋势：单一工具应该专注于核心功能，而将辅助功能交给生态中的其他工具。

未来发展方向

虽然纯模式检查功能已经存在且无法轻易移除，但 LightningCSS 团队明确了未来的方向：

1. 不再增加新的样式检查规则
2. 保持现有功能的稳定性
3. 鼓励开发者使用专业 linting 工具进行样式质量管控

这一决策体现了对工具职责清晰化的追求，同时也为现有项目提供了平稳过渡的方案。

实践建议

对于正在使用或考虑使用 LightningCSS 的团队：

1. 评估纯模式检查对项目的实际价值
2. 对于必须使用豁免的情况，采用标准注释语法
3. 考虑结合专业 linting 工具建立完整的样式质量保障体系
4. 在框架集成场景下，积极与框架维护者沟通配置需求

这种平衡的实践方式既能享受工具带来的好处，又能保持项目的灵活性。