Jest 快照不匹配 - Windows vs Unix/Linux 行尾

Posted 2023-02-22

【中文标题】Jest 快照不匹配 - Windows vs Unix/Linux 行尾

【英文标题】：Jest snapshots not matching - Windows vs Unix/Linux Line Endings

【发布时间】：2018-11-22 05:24:18

【问题描述】：

我们有一个由多个开发人员在多个操作系统上开发的项目。我们在更漂亮的配置中将字符限制设置为 120 个字符。我们的 windows 机器生成的快照与我们的 linux/unix 机器不同。

窗口：

              <h4
                className="RightPanel__item--heading heading--headingBlocks
subHeading--headingBlocks subHeading--different"
              >

而在我们的 linux/unix 机器上，快照会生成以下行：

              <h4
                className="RightPanel__item--heading heading--headingBlocks subHeading--headingBlocks subHeading--different"
              >

对于 linux/unix 快照，代码在第 119 列结束，而 Windows 机器在最后几个属性之前生成一个新行。 我们使用 React，使用 Jest 进行测试，使用 eslint 进行 linting，使用 Babel 进行转换。

相关配置

babelrc: 转换: "^.+\.jsx?$": "babel-jest" eslintrc: "globals": "jest": true prettierrc: "printWidth": 120 prettierignore: *.snap

项目

React, Babel, Webpack, vanilla es6+ no typescript project with jest for testing

研究

我们尝试设置 eslint 的 "linebreak-style": ["error", "unix"] 以查看 eslint 更改是否会更新修复 Windows 的开玩笑快照，但无济于事。我们已确保跨机器安装相同版本的 jest。与 prettier 和 eslint 相同。

关于我们如何解决此问题以使测试不会在一个或另一个操作系统上失败的任何建议？

【问题讨论】：

你在生成的快照文件上运行得更漂亮吗？

不，我实际上不确定 120 个字符的限制是如何在这里发挥作用的。在我们的 .prettierignore 中有 *.snap。我们的 eslint 配置中没有 120 个字符的限制

这很奇怪，例如如果将限制增加到 130 就不会发生这种情况？

如果我在我的 prettierrc 中将字符长度增加到 130 甚至 160，它实际上并没有改变快照。我去看看我的 eslint extends 看看有没有字数限制。

如果是这样，那么这可能与更漂亮的关系无关。也许您可以通过（暂时ofc）一一丢弃依赖关系来将问题缩小到更接近开玩笑本身。这听起来像是一个玩笑的错误

【参考方案1】：

我们在我们的项目中使用快照序列化程序来避免此类问题，它也应该对您的情况有所帮助。对于 html 快照，我推荐jest-serializer-html

【讨论】：

这不会改变任何东西，也不会回答 OP。 jest-serializer 使快照漂亮但不影响行尾。为了输出 CRLF 或 LF，测试本身必须采用所需的格式。您可以在 CLI (npmjs.com/package/crlf) 中使用 crlf 在运行 jest 之前转换文件。

@MarionLP 这里的问题是换行符在不同操作系统上的插入方式不同，而不是换行符用不同的字符序列表示。

【参考方案2】：

我们遇到了完全相同的问题，即 Windows 机器生成的快照具有与 Mac 不同的换行符。

我们发现 VS Code 在 windows 机器上设置为 LF 换行设置，更改为 CRLF 解决了这个问题。

我建议检查编辑器中的行尾设置以及链中任何其他位置。

【参考方案3】：

在团队中同步此类内容的最佳方式是使用 EditorConfig。大多数代码编辑器都支持它，无论是原生还是通过扩展。

EditorConfig 是一种指定编辑器设置的通用方法，在您的情况下为行尾，所有操作系统上的所有代码编辑器都尊重这一点。

https://editorconfig.org

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf