龙陌的博客

外观

目录 ​

在代码注释中，除了常见的 TODO、FIXME 和 XXX 外，还有一些其他的特殊注释标签也被开发人员广泛使用，用于标记代码中不同类型的待处理项。以下是一些类似的注释标签：

TODO - 表示这里有待完成的任务或者待实现的功能。

FIXME - 指出代码中存在问题或bug，需要修复的地方。

XXX - 表示代码可能包含临时解决方案、糟糕的实践、或者有待优化的部分，通常意味着此处的实现方式并不理想，应在未来重新审视和改进。

除此之外，还有其他一些非标准但同样常用的注释标签：

HACK 或 HACKER - 标记一段临时性的、非常规的解决方案，通常用于应对紧急问题，但长期来看不是最优解。

OPTIMIZE 或 PERFORMANCE - 标记可能影响性能的地方，需要进一步优化。

REVIEW - 请求他人复查某段代码，可能是为了确认设计决策、逻辑是否正确或改进代码质量。

DEPRECATED - 标记已弃用的代码，提醒开发者这段代码未来可能会被移除。

NOTE 或 NOTICE - 提供一些重要提示或背景信息。

UNDONE 或 WIP (Work In Progress) - 标记正在进行的工作，表明这部分代码尚未完成。

不同的开发环境和团队可以根据自身需求自定义这些特殊注释标签，并且有些集成开发环境（IDE）如Eclipse、IntelliJ IDEA、PyCharm等支持对这些标签进行高亮显示，并在任务列表或问题面板中集中管理。

@umijs/fabric 是 umi 3 时在 ant-design-pro 脚手架里使用的，@umijs/lint 是 umi 4 结合到框架层的最佳实践，可以理解为后者是前者迭代后的新版本，新项目推荐用后者。 ​

从两者的介绍看，@umijs/fabric 只包含 prettier，eslint，stylelint 的配置，使用时依然需要调用 prettier，eslint，stylelint 的CLI； 而 umi@4 下的 @umijs/lint 不仅包含配置还有统一的 CLI，提供 umi lint CLI，集成式调用 ESLint 和 Stylelint，但却不包含 prettier。

至于为啥会有 @umijs/lint，他相比 @umijs/fabric 有哪些好处，我贴下之前在内网发的相关帖子。 https://github.com/umijs/fabric/issues/147 Umi 4 特性 05：稳定白盒性能好的 ESLint

ESLint 大家都很熟，通过很多规则，让大家写更好的代码，而且部分规则还能自动修复。Umi 3 也有 lint 命令，包含 eslint、prettier、stylelint 等。 Lint 虽然不是卡点，但大家在这块遇到问题的比较多，同时带来了不少咨询量。

问题主要集中在这些方面，

1、规则开太多，有些规则见仁见智，不同人有不同的想法 2、依赖不稳定，睡一觉醒来规则变了，CI 过不了影响发布节奏 3、太黑盒，不知道开了什么规则，甚至框架（Umi）层自己都不敢更新依赖 4、性能不好，影响提交和 CI 速度

以上问题，Umi 4 的 Lint 方案全解。

规则开太多是因为 Umi 3 对于 ESLint 的定位不清晰。ESLint 的规则分质量类、建议类和风格类。比如使用未定义的变量是质量类，比如语句后加不加逗号则是风格类。 在拥有 prettier 之后，Umi 4 的方案里，风格类的全交给 prettier，ESLint 则只负责可能导致问题的质量类。经过筛选，Umi 4 开的规则仅 60 多条。

依赖不稳定是 ESLint 的设计缺陷。ESLint 生态包含 config 和 plugin，plugin 实现规则，config 决定规则的开启或关闭。 这理应是不错的设计，但可惜 ESLint 只考虑了项目级如何使用，却没有考虑三方库封装 config 和 plugin 的场景。 具体的问题是 ESLint 找 config 和 plugin 只会从项目根目录去找。而 npm client 都有 hoist 依赖的特性，导致往上提到根目录的依赖是不是正确有一定运气成分。

所以依赖不稳定有两个原因， 1）由于 npm client 的原因导致出现错误的 eslint config 或 plugin， 2）config、plugin 或其依赖和间接依赖更新导致的 break change。

对于依赖不稳定，Umi 4 有不同的解。短期的现在的解是通过 @rushstack/eslint-patch/modern-module-resolution 进行 hack，修改 config 里找 plugin 的规则，改从 config 所在路径开始找。这可以确保 plugin 版本找正确，但无法避免 plugin 及其依赖更新后的功能变更。所以，更长期的未来的解是预打包 config 和 plugin 依赖，但由于 eslint 设计上的问题，还需要调研 hack 的方式。

太黑盒是因为之前有继承其他 config。 Umi 4 的实现里，不再继承任何其他 config，只使用提供规则功能的 plugin，然后具体开什么规则是直接一个列表写死，只列我们需要的规则。 这样三方或者 eslint 官方规则启用开启的变更，都不会影响到 Umi 的用户，同时框架层也可以放心地更新依赖。

性能不好和 TypeScript 有关。 Umi 3 会根据项目 TypeScript 文件的占比，决定是否开启 TypeScript 相关的 Lint 规则，而这些规则中，有一些是 type-aware linting。 type-aware 的规则和类型相关，由于 TypeScript 的语言特性，比如跑一遍完整的项目才能确定类型是否正确，所以每次 lint 就算只改了一个文件，也需要跑整个项目。 这里有把雨燕的 commit 时间从 19s 优化到 1-3s 的记录。而 Umi 4 中，压根不会开 type-aware 的规则，因为这些规则更多也是风格类，和质量无关。

附umi4的编码规范

安装教程 ​

devDependencies

目前 @umijs/lint 使用的 stylelint 版本是 v14

json
{
  "devDependencies": {
    "husky": "^8.0.1",
    "eslint": "^8.23.0",
    "lint-staged": "^13.0.3",
    "prettier": "^2.7.1",
    "prettier-plugin-organize-imports": "^3.0.0",
    "prettier-plugin-packagejson": "^2.2.18",
    "stylelint": "^14.9.1",
    "@commitlint/cli": "^17.1.2",
    "@commitlint/config-conventional": "^17.1.0",
    "@umijs/lint": "^4.0.0"
  }
}
json
{
  "commitlint": {
    "extends": [
      "@commitlint/config-conventional"
    ]
  },
  "lint-staged": {
    "*.{md,json}": [
      "prettier --cache --write --no-error-on-unmatched-pattern"
    ],
    "*.{css,less}": [
      "stylelint --fix",
      "prettier --cache --write"
    ],
    "*.{js,jsx}": [
      "eslint --fix",
      "prettier --cache --write"
    ],
    "*.{ts,tsx}": [
      "eslint --fix",
      "prettier --cache --parser=typescript --write"
    ]
  }
}

或

json
{
  "lint-staged": {
    "*.{jsx,less,md,json}": [
      "prettier --no-error-on-unmatched-pattern --cache --write"
    ],
    "*.ts?(x)": [
      "prettier --no-error-on-unmatched-pattern --cache --parser=typescript --write"
    ]
  }
}
json
{
  "scripts": {
    "prepare": "husky install",
    "format": "prettier --cache --write .",
    "prettier": "prettier --write \"**/*.{js,jsx,tsx,ts,less,md,json}\"",
    "lint": "npm run lint:es && npm run lint:css",
    "lint:css": "stylelint \"{src,test}/**/*.{css,less}\"",
    "lint:es": "eslint \"{src,test}/**/*.{js,jsx,ts,tsx}\""
  }
}

.editorconfig ​

text
# http://editorconfig.org
root = true

[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true

[*.md]
trim_trailing_whitespace = false

.eslintrc.js ​

js
module.exports = {
	extends: require.resolve('@umijs/lint/dist/config/eslint'),
};

.prettierrc.js ​

js
module.exports = {
	pluginSearchDirs: false,
	plugins: [
		require.resolve('prettier-plugin-organize-imports'),
		require.resolve('prettier-plugin-packagejson'),
	],
	printWidth: 80,
	proseWrap: 'never',
	singleQuote: true,
	trailingComma: 'all',
	overrides: [
		{
			files: '*.md',
			options: {
				proseWrap: 'preserve',
			},
		},
	],
};

.stylelintrc ​

text
{
	"extends": "@umijs/lint/dist/config/stylelint"
}

tsconfig.json ​

json
{
  "compilerOptions": {
    "target": "es6",
    "module": "es2015",
    "importHelpers": true,
    "strict": false,
    "declaration": true,
    "skipLibCheck": true,
    "esModuleInterop": true,
    "allowJs": true,
    "allowSyntheticDefaultImports": true,
    "forceConsistentCasingInFileNames": true,
    "moduleResolution": "node",
    // node环境
    "resolveJsonModule": true,
    "isolatedModules": true,
    "noEmit": true,
    "jsx": "react",
    "baseUrl": "./",
    "paths": {
      "@@/*": [
        ".dumi/tmp/*"
      ],
      "@longmo/ui": [
        "src"
      ],
      "@/*": [
        "./*"
      ],
      "@/": [
        "./packages"
      ],
      "@longmo/ui/*": [
        "src/*",
        "*"
      ]
    }
  },
  "include": [
    "typings.d.ts",
    // 配置的.d.ts文件
    "src/**/*"
  ],
  "exclude": [
    "node_modules",
    "lib",
    "__tests__"
  ]
}

Contributors ​

作者:Long Mo
字数统计:1.9k 字
阅读时长:7 分钟
Long Mo
文章作者：Long Mo
版权声明： 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来自 Longmo Docs ！

Copyright © 2024-present Longmo