wotan

Fimbullinter项目

可插入的打字稿和JavaScript Linter

可用的软件包

沃坦

具有精心选择的内置规则的主衬里运行时。可自定义您自己的规则，处理器，格式化器，可共享配置和插件模块。

请参考文档以详细说明可用规则，配置和使用情况。

vé

VUE单文件组件（SFC）的官方处理器。从您的*.vue文件中提取脚本内容以进行覆盖。

海姆德尔

兼容层允许在Wotan运行时使用TSLINT规则和格式化器。

瓦尔提尔

使Wotan的行为几乎像Tslint。重复您现有的tslint.json而没有任何更改。

Bifröst

允许TSLINT规则和格式化器的作者提供其在Wotan内部使用的软件包。使用Bifröst的规则和格式化者不需要Heimdall才能正确运行。

伊米尔

为自定义规则和插件作者提供核心类型。

米米尔

包含所有核心规则，格式化和配置预设。

mithotyn

语言服务插件用于打字稿。输入时提供实时的编辑覆盖物。

进一步的文档

• 了解打字稿的API
• 写作规则
• 测试规则
• 使用本地规则
• 编写可共享配置
• 使用API

食谱

• 用TSLINT规则覆盖VUE文件
• 替换tslint --type-check
• 检测未使用的变量

这是什么意思？

这些名字怎么了？

北欧神话：

Fimbullinter来自Fimbulwinter，这是Ragnarök事件之前持续的3年持续的3年。 “ fimbul”的意思是“伟大”，“ Linter”是一种检测和警告某些编码模式的工具。

沃坦是奥丁（Odin）的众多名字之一。您可能还以Woden，Wodan，Wensley等的名字认识他。Woden是牺牲的神，嗜血和残酷。他一直在努力争取智慧。从他的宝座上，他可以看到九个世界中的一切发生。

Vé是沃登（Woden），维利（Vili）和韦利（Vili）的三个混乱中最年轻的人，他们共同杀死了巨大的伊米尔（Ymir），并从他的身体中创造了九个世界。

对于第一对人，询问和Embla，奥丁赋予了灵魂和生命。维利给予了机智（智慧）和触觉。 Vé进行了容貌（外观，面部表情），言语，听力和视觉。

Heimdall （也称为Heimdallr），位于燃烧的彩虹桥Bifröst遇见天堂的地方，一直关注Ragnarök的发作。

Bifröst是燃烧的彩虹桥，它将人类世界与众神领域联系起来。

瓦尔蒂尔（Valtýr）来自“瓦尔”（Valr）（死者，在战斗中被杀）和“týr”（上帝），是指被杀的上帝，经常被用来指代奥丁。

伊米尔（Ymir）是整个世界的巨人。他是所有约纳尔的祖先。

米米尔（“记住，智者”）以其知识和智慧而闻名。奥丁神围绕着米米尔的头部，它背诵了他的秘密知识和忠告。

Mithotyn （实际上是“Mitoðinn”，意思是“命运的分配器”）引入了没有的规则。在前往外国土地时，填补了奥丁的位置。

为什么还有另一个衬里？

这是试图避免其他局限器的设计决策，这些衬里有问题：

• 根据其来自的软件包，避免使用规则名称来避免姓名冲突。
  • TSLINT将所有规则都放在全球名称空间中，并将它们搜索到所有可用规则目录中。目录的顺序很重要，而核心规则替代则优先。
  • ESLINT允许本地规则目录作为CLI标志。该目录中的规则可以覆盖核心规则。
• 配置文件的依赖项相对于该文件解决。
  • TSLINT已经做到了。
  • ESLINT不支持这一点。
• 共享配置和插件之间没有区别。实际上，两者都是可扩展的配置，可以选择提供规则目录，设置，规则和处理器。
  • TSLINT允许您在extends和rulesDirectory之间进行选择。软件包的规则目录是实现细节，不应是用户配置的一部分。
  • Eslint处理配置和插件完全不同。实际上，他们试图弃用可共享配置以支持插件。
• 懒惰的规则以减少启动时间。
  • TSLINT已经做到了。
  • ESLINT期望插件作为已经加载的对象提供规则。如果您只使用一些大包装规则，这会导致很多开销。
• 文件系统访问和配置的缓存。由于缓存是DI服务，因此API用户可以在需要时清除缓存。
• 从一开始就支持处理器。启用 *。vue文件等等。
• 具有配置规则的别名。可以用来将ESLINT的no-resticted-syntax作为每个配置选项的不同命名规则，将其视为将规则视为规则。
• 整个API由DI容器提供动力。这使得很容易注入其他服务。您甚至可以通过CLI使用插件来注入不同的服务。
• “全局”配置文件（除了.wotanrc.yaml ）用于CLI默认值和插件配置： .fimbullinter.yaml 。此文件也可以由编辑插件使用，因此无需复制通用配置。
  • Eslint没有这样的文件，将来拒绝添加一个文件。如果您只需要使用CLI默认值创建此类配置文件，则不需要像standard或xo这样的工具。
  • tslint Startet将其塞入他们的tslint.json中，这会导致困惑的用户。
• 报告未使用和冗余的启用和禁用的评论（或其部分），并用--report-useless-directives 。
  • ESLINT仅报告未使用的禁用评论。它仅报告完全未使用的评论。没有报告冗余评论，也没有启用对不存在的规则的评论。
  • TSLINT不支持这一点。

TSLINT的差异

• 要扩展插件或可共享配置，请使用extends: plugin-name 。该名称将根据Node的模块分辨率算法进行解决，相对于配置文件。
• 要使用项目中维护的规则，请使用rulesDirectory: {"my-prefix": "./path/to/rules"}并将它们作为my-prefix/rule-one: "error"配置。规则目录是相对于配置文件的路径。
• 覆盖：您可以通过指定一个或多个替代来覆盖主要的辅助化。如果文件名匹配覆盖的范围模式，则应用该替代的所有设置。按顺序处理覆盖，后来从替代之前覆盖了覆盖设置。
  • 模式相对于它们指定的配置文件匹配。
  • 没有斜线的模式仅与每个文件的Basename匹配。
  • 要限制与当前目录的匹配，请以./将图案前缀。
  • 被否定的模式可用于从上述模式的匹配中减去。
• linterOptions.exclude > exclude
  • 扩展配置时，不包括不覆盖。
  • 模式匹配遵循与覆盖相同的规则（请参见上文）。
• JSON5支持配置文件。
• 规则和处理器可以拾取规则无关的设置。
• 处理器，甚至支持--project 。
• 别名，见上文
• 一种理智而安全的修复方法：
  • 没有使用语法错误修复文件。
  • 不包括重叠的替换，以防止破坏您的代码。
  • 每个文件运行可配置的迭代数量，以在下一个迭代中应用相互矛盾的更改。
  • 如果修复会引入语法错误，请停止。
  • 使用--project并不能从头开始创建整个程序，这使其迅速迅速。
• 测试
  • 测试是在JSON文件中配置的，可以配置您可以指定的所有内容
  • 测试文件不包含错误标记。这避免了语法错误并使它们更易于维护。皮棉结果和固定内容存储在单独的基线文件中。
  • 可以通过不同的设置对相同的代码进行测试。
• 支持打字稿项目参考。
• 从.fimbullinter.yaml加载CLI选项的默认值。
• 不使用未选中的JavaScript文件中的类型信息（ // @ts-nocheck或"checkJs": false ）。
• 报告未使用和冗余的启用和禁用的评论--report-useless-directives 。

支持的环境

该项目在Node.js的所有积极支持的版本上运行。

该项目正式支持最新的3个稳定版本的打字稿。撰写本文是3.0-3.2。它应该与Typescript的夜间构建（ typescript@next ）一起使用，但不能保证。

自定义规则至少应使用ES6来支持本机类。否则，当尝试扩展从任何软件包导出的类时，您会遇到问题。

语义版本（SEMVER策略）

配x以下政策确实仅适用于尚未到1.x和以下版本。 0.x范围内的每个版本都被认为是实验性的。可以并且将在没有贬值的情况下破坏API的变化。

从理论上讲，对规则的每一个更改都可以破坏用户，并且可以被认为是破坏的变化。为了避免为每个错误修复发布新的主要版本，我们的准则略有不同，如下所述。

预发行（夜间构建）

• 不能保证稳定
• 标记为NPM上的next ，因此您可以安装@fimbul/wotan@next
• 包含用于下一个版本的最新更改
  • x.0.0-dev*包含所有更改，包括打破下一个主要版本的更改
  • xy0-dev*包含下一个次要版本的所有更改
  • 补丁版本没有预发行

补丁发布

• 修复崩溃
• 修复回归
• 内部功能的重构不会改变用户面向行为

次要版本

• 添加新规则，规则选项，格式化器，处理器，API
• 规则可以添加可能导致新发现的新检查
• wotan:latest
• 规则可以改变他们的查找消息
• 用于人类消费（例如stylish ）的格式化器可以改变其输出
• 可以弃用规则，规则选项，格式化器，处理器和API
• 新的配置选项可以添加到配置文件中

主要版本

• 包含破坏API的变化
• 删除先前弃用的规则，选项，格式化器等。
• 用于机器消耗的格式器（例如json或tap ）可以更改其输出
• wotan:recommended已更新到wotan:latest

发布时间表

当前没有固定的发布时间表。如果主人发生变化，则每晚都会出版夜间版本。一旦确定并修复了错误，就会立即发布补丁发布。如果主人发生更改，则每周或两周发布次要版本。一旦出现了足够的破裂变化，就会发布主要的发行版。

执照

Apache-2.0©Klaus Meinhardt