Sinon: 否则 2.0 发布

我想根据/docs已有的工作创建一个新的文档网站。 我希望在下周的假期里花一些时间在这上面。

@mroderick如果您将工作推到某个地方，请告诉我。 我也许可以帮助处理文档！

更新了复选框。 不确定是否应该选中“迁移 sinon.sandbox”，但至少 PR 已关闭。

@jonnyreeves ：不知道为什么我们应该删除sinon.test 。 这是一个围绕测试的沙箱，它会在测试结束后自动清除任何创建的存根并进行监视。 这减轻了人们对beforeEach和afterEach函数的负担。 非常有用，与测试框架关系不大。

用户需要看到一个简单的替代方案，以便将其删除以支持其他（更好）的东西。

我自己从未使用过sinon.testCase ，可能是因为它的 api 适合 BusterJS（其中每个测试用例都是测试套件的属性）而不是 Mocha（其中每个测试都是在测试套件主体中运行的匿名函数） ）。

@fatso83我对sinon.test的主要问题是它依赖于sinon.config单例。 恕我直言，用户可以通过在其测试框架的beofreEach和afterEach挂钩中创建（和恢复）沙箱来获得更多控制权。

如果我们要在公共 API 中保留sinon.test （和sinon.testCase ）； 那么我们需要解决这两个问题——虽然长期以来一直是 sinon 的用户/支持者，但我对他的项目不熟悉——我们应该如何达成共识？

@jonnyreeves好的，当您提到它依赖于sinon.config时更有意义。 恕我直言，明确创建和恢复沙箱是可以的，只要我们将其作为替代方案提供给来自 Sinon 1 并想知道sinon.test发生了什么的人。 所以文档应该是这样的

sinon.test

_这在版本 2 中已被弃用，以支持显式创建沙箱。 见link to sandbox ._

我完全赞成版本 2 中更精简的 API，因此其他 NPM 模块或其他现有功能可以更好地提供诸如typeOf 、 extends和sinon.test* 。

我认为像npm install sinon-test和var sinonTest = require('sinon-test')(config);可能是一个不错的替代品。

:+1: 将这样的实用程序移动到单独的 npm 模块中。 core代码更少

感谢您的投入； 我已经更新了顶部的概述以反映到目前为止的讨论（主要是去除问号，使任务更清晰），请看一看。

此外，我们能否在以下方面获得类似的关闭：

• 删除sinon.log和sinon.logError （两者都由 fake_server 使用；并且可能最好作为配置传递给这些实例）
• 从 2.0 中删除sinon.mock

谢谢

我从未使用过sinon.testCase ，但是我是sinon.test的重度用户。 我对它进入一个单独的库很好，但只是不要忘记：有很多人使用不支持beforeEach设计（例如磁带）的测试框架，并认为这些设置函数导致耦合的测试用例。 如果没有简单的直接替换，我们可能会给这些用户带来很多问题。

我想我们可以提供这样的迁移路径：

sinon.test = require('sinon-test');

@mantoni ：很好的建议。 通过仅分配给现在未使用的test属性，只需在测试中多加一行，就可以为人们提供最少的麻烦。 我们只需要确保sinon对象在某个时候没有被冻结（如Object.freeze(sinon) ）......

@jonnyreeves ：关于sinon.mock我记得@mroderick建议等到 2.0 发布后再删除它。 我们已经表示它已被弃用有一段时间了，所以在 2.0 版本之后删除它应该没问题，恕我直言。 但是因为我们已经有了 CommonJS 支持，我不介意在 2.0 版本之前删除它 _if_ 我们已经将代码提取到它自己的模块中。 然后人们可以let sinon.mock = require('sinon-mock') ，如果他们很高兴的话。

关于sinon.log* ，如果我们可以在需要时将它们作为配置提供，我认为没有理由坚持将它们作为公共功能。

WRT 分解出sinon-test ，请注意我们需要允许消费者提供配置，即：

sinon.test = require('sinon-test').withConfig({ ... });

或类似。

刚刚在创建sinon-test包时发现了另一个可能的 API 更改； 关于sinon.assert会发生什么的任何想法？ 同样，这对我来说并不是 sinon API 的核心部分，可能更适合迁移到sinon-test包以及sinon.test和sinon.testCase ？

@fatso83 @mantoni @cjohansen； 我有一个sinon-test包的工作版本准备审查 - 你们中的一个人能否以sinonjs/sinon-test初始化一个空的 git repo，这样我就可以提出一个 PR 反对它吗？

谢谢

那很快！ https://github.com/sinonjs/sinon-test

@cjohansen你

完毕

谢谢，公关提出 - 欢迎反馈： https :

@mroderick如果您将工作推到某个地方，请告诉我。 我也许可以帮助处理文档！

@spinningarrow那就太好了。 我已经创建了 #991 来与其他工作分开跟踪。 我将在接下来的几天内根据我的想法更新它，我们可以从那里开始。

我们不时遇到一些与模拟有关的问题。 现在@jonnyreeves已经完成了实际提取模块的艰苦工作，如果模块是自己的，那么将模块移动到存储库中是否有意义？ 然后我们可以将所有与模拟相关的讨论移到那里，并在此处关闭问题。 这主要是为了减轻管理负担。

我们不时遇到一些与模拟有关的问题。 现在@jonnyreeves已经完成了实际提取模块的艰苦工作，如果模块是自己的，那么将模块移动到存储库中是否有意义？ 然后我们可以将所有与模拟相关的讨论移到那里，并在此处关闭问题。 这主要是为了减轻管理负担。

这也意味着使该存储库与开发工具等保持同步的管理负担。
也许我们应该确保首先设置简单的共享开发工具？ 抄送： @mantoni

@mroderick @fatso83好的，让我们看看我们是否可以推出 2.0。

我已经更新了这个问题的概述，以涵盖我认为所有未完成的迁移（包括测试套件的 CJSification，如果您正在阅读本文 - 帮助！） - 请看一看，如果您同意，请告诉我出色的工作。

此外，我想就以下几点达成共识：

1. 我们应该从公共（ sinon. ）API 中删除typeOf和extend ，还是应该等待 Sinon 3.x ，它（我假设）将进行 API 的现代化.
2. 我们应该从 2.0 中删除旧的 IE 支持/黑客吗？ 这 _may_ 简化了迁移，因为我们可以删除“fakeXDM”代码 - 我没有仔细观察，所以我还不能真正估计这项工作。
3. 发布新的文档站点是 2.0 版本的先决条件吗？ 我担心它没有太大的吸引力:)

谢谢大家。

@jonnyreeves ：今晚你肯定是个忙碌的蜜蜂😺。 我有一个很长的假期，所以我当然可以帮助测试套件的出色迁移（下面有一个“但是”）。

关于你的观点：

1. 他们应该去。 我认为这已经基本解决了（参考，上面的概述）。
2. 让我们先定义“旧版 IE”。 版本 < 10，还是整个sinon-ie包？ IE9 仍然带有一些奇怪的 CORS 替代品，称为 XDR。 如果有人仍然打算支持 2012 年之前发布的 IE 版本，他们总是可以使用 1.x 分支，我猜。 不确定 XDM 指的是什么？ 我不确定哪些浏览器版本需要sinon-ie ，所以我不能对不需要的包过于夸张。 我们应该确定后果。
3. 文档 _is_ 现在是一个痛点，但我有点不确定在这里要说什么。 在帮助解决上述其他问题之前，我可以开始深入研究 #991。 有地方推送文档会让生活更美好。

好奇这是什么状态？ 看起来自 6 个月前以来没有太大进展； 由于各种原因，我目前正在依赖预发布（功能性符号支持是一个巨大的支持）-我不是要推动，而是一个简单的“有一个时间线'/'目前还没有时间线'会很棒！ <3

@ELLIOTTCABLE因为我们没有资金，所以没有固定的时间表。 随着我们在维护者组中的进展——或其他志愿者，比如你自己——有时间在上面的列表上工作。 话虽如此，我认为如果您不厌其烦地多逛逛，我认为您可以自己回答“状态”问题😉：

1. 即使您在上面看到“...于 2016 年 7 月 8 日引用”，也仅表示列表中的第一条评论来自该日期。 最新一期，#1235，引用了这个“12 天前”。
2. 问题清单几乎完整 - 与半年前不同。

所以......我们正在取得进展，但监督先前版本的错误修复以及不断提供新功能，占用了我们大量的维护时间。 只是研究和写这个最后花了半小时😅

基本上，在查看上面的列表后，只剩下两个主要问题：

• “迁移 fake_server 和朋友”（90% 已解决，仅剩一点点 - 见上文）。
• 发布网站（参见 #1220：一件小事、超级简单的事情和一项中等任务）

根据#1221 中的讨论，我认为上面的大多数其他 uncloses 复选标记与旧的 IE 版本 (6-10) 相关，我很确定它们不会得到支持，因此可以忽略它们。 现在将解决这个问题。

@sinonjs/sinon-core：之前的评论让我意识到我们上面有一些问题，根据 #1221 中的讨论，我们不太可能完成：

1. 删除旧版 IE 支持/解决方法？
2. 修复 xdomain

如果我们无论如何都不会碰它们，我是否会创建一个 PR 来删除旧的 IE 位？ 我认为xdomain也可以最终进入历史垃圾填埋场，因为那主要是 IE 专用的 CORS 类似黑客，因此可以将其删除吗？

@fatso83 啊，k。 我错过了对所引用问题的更新评论。 我希望为我复习这个对你有用！

无关：看起来部分原因是放弃对 IE6 的支持。 那真不幸。 啊好吧，c'est la Marche du progrès！ /=

我们基本上就在那里，文档站点有它自己的问题。

嘿，伙计们 - 有什么能阻止我们将 2.0 标记为“稳定”的 sinon 版本并杀死 1.x？ :)

认为我们想要#1297 作为最后一件事。

预计到达时间？ 我建议我们不迟于下周发货，如果没有完成，就推迟那个功能。

你们很漂亮。 <3