一个好的目录结构设计就成功了一半---如何在项目中约束目录和文件名编程中的命名规范是：camelCase（驼峰命名法）PascalCase（帕斯卡命名法，又称大驼峰命名法）snake_case（下划线命名法）kebab-case（中线命名法）Hungariannotation（匈牙利表示法——一种非常系统和古老的命名规范）背景入职后，一个新的模块需求是收到，作者可以自由创建代码文件目录和文件。上线前回头看了下代码，我的天，一会儿大写，一会儿小写，一会儿驼峰。我以前好像没那么随便。为什么我以前不乱写？答案是有CI和CD流水线卡控，不符合规范的代码无法进入master。缺乏对问题代码的文件目录和文件命名的约束，会导致代码的野蛮生长。有人说：设计好目录结构就成功了一半。该方案通过正则表达式匹配文件路径。问题来了：我既不能正则化也不能获取文件路径。寻找工具，所以我找到了ls-lint。https://ls-lint.org/ls-lint：ls-lint是一个极快的文件和目录名linter，它提供了一种简单快速的方式来为你的项目目录带来一些结构以前端为例来介绍使用方法：添加依赖npminstall@ls-lint/ls-lint#本地添加配置文件.ls-lint.ymlls:src:.js:kebab-case.ts:kebab-case.d.ts:kebab-case.vue:kebab-caseignore:-.git-node_modulesls-lint的配置非常灵活，可以根据后缀名和子目录分别设置规则。规则包括：lowercase,camelcase,pascalcase,snakecase,screamingsnakecase,regex执行命令npx@ls-lint/ls-lint执行时机GitHook的pre-commit阶段允许开发者在流水线之前的某个阶段感知和修改触发器goesonlineintime命令，防止开发者在本地使用--no-verify绕过，双重保险。其他的lint比如eslint、stylelint、commitlint，表面上可能会让一些同学用起来不爽，但从长远来看，代码规范是非常有必要的。eslint-plugin-filename和eslint-plugin-folders能否解决上述问题还有待考察。
