Sublime Text 不直接开发 ESLint 规则，而是通过 SublimeLinter-eslint 插件调用本地 ESLint 实例来展示自定义规则结果；规则需在 Node.js 中按规范编写、发布为 npm 包，并在 .eslintrc.js 中配置启用。
Sublime Text 本身不直接支持自定义 ESLint 规则的开发，但它可以作为编辑器，配合 ESLint 进行静态代码分析，从而强制执行团队规范。真正开发自定义 ESLint 规则，是在 Node.
js
环境中编写规则逻辑，再通过 Sublime 的 ESLint 插件（如
SublimeLinter-eslint
）调用本地或项目级 ESLint 实例来生效。
如何开发一个自定义 ESLint 规则
自定义规则本质是一个导出对象的 JavaScript 文件，需符合 ESLint 插件规范：
规则文件放在插件目录下（如
），必须导出
（含类型、修复性等描述）和
函数
返回一个访问器对象，监听 AST 节点（如
），检查
可拦截
用
报告问题，支持自动修复（
）
规则需发布为
npm
包，或以
命名，在项目中安装并配置到
在 Sublime 中启用并验证自定义规则
Sublime 不运行规则，只展示 ESLint 的输出结果。关键在于确保它调用的是你修改后的 ESLint 环境：
Eclipse导入Android或其他的JAVA项目的正确方法 WORD版
本文档主要讲述的是Eclipse导入Android或其他的JAVA项目的正确方法；希望本文档会给有需要的朋友带来帮助；感兴趣的朋友可以过来看看
下载
确认已安装
SublimeLinter
和
SublimeLinter-eslint
（通过 Package Control）
在 Sublime 的
Preferences → Package Settings → SublimeLinter → Settings
中，设置
，确保走项目本地 ESLint
在项目根目录的
中启用你的规则：
，并正确配置
保存 JS 文件后，Sublime 底部状态栏或行号旁会实时显示规则警告，悬停可看详情
让团队规范真正落地的小技巧
光有规则不够，还需降低使用门槛、提升一致性：
把插件和规则封装进公司内部 npm 包（如
），统一维护、语义化发版
在
的
中加入
和
结合 Husky + lint-staged，在 commit 前自动检查，阻断不合规代码入库
为每条自定义规则写清晰文档：为什么加？什么算违规？怎么改？是否可自动修复？附示例代码对比
基本上就这些。开发规则不复杂但容易忽略环境链路——Sublime 是“眼睛”，ESLint 是“大脑”，而你的规则是“判断标准”。三者对齐了，团队规范才真正可感知、可执行、可延续。
my-eslint-plugin/rules/no-console-log.jsmetacreatecreateCallExpressionnode.callee.name === 'console' && node.arguments[0].type === 'Literal'console.log('xxx')context.report()fix: fixer => {...}eslint-plugin-xxx.eslintrc.js"eslint" : {"executable": "./node_modules/.bin/eslint"}.eslintrc.js"my-plugin/no-console-log": "error"plugins: ["my-plugin"]@ourorg/eslint-config-teampackage.jsonscripts"lint": "eslint . --ext .js,.jsx""lint:fix": "eslint . --ext .js,.jsx --fix"