Sinon: それ以外の場合は2.0リリース

すでに/docsにある作業に基づいて、新しいドキュメントWebサイトを作成したいと思います。 来週の休暇中に、それに数時間を費やしたいと思っています。

@mroderickどこかにプッシュされた作品がある場合は、私に知らせてください。 私はドキュメントを手伝うことができるかもしれません！

チェックボックスを更新しました。 「Migratesinon.sandbox」をチェックする必要があるかどうかはわかりませんが、少なくともPRは閉じられています。

@jonnyreeves ： sinon.testを削除する理由がわかりません。 これは、作成されたスタブをクリーンアップし、テスト後に自動的にスパイするテストの周りのサンドボックスです。 これにより、多くのbeforeEachおよびafterEach関数から人々が軽減されます。 非常に便利で、テストフレームワークとはほとんど関係がありません。

ユーザーは、これを削除して他の何か（より良い）を優先するために、これに代わる簡単な方法を確認する必要があります。

私はsinon.testCase自分で使用したことがありません。おそらく、そのAPIがBusterJS（各テストケースがテストスイートのプロパティである）に適合し、Mocha（各テストがテストスイートの本体で実行される匿名関数である）に適合しないためです。 ）。

@ fatso83 sinon.test私が抱えている主な問題は、それがsinon.configシングルトンに依存しているという事実です。 IMHOユーザーは、テストフレームワークのbeofreEach afterEachフックと

sinon.test （およびsinon.testCase ）をパブリックAPIに保持する場合。 次に、これらの問題の両方に対処する必要があります-長年のユーザー/ sinonのサポートですが、私は彼のプロジェクトをハッキングするのは初めてです-どのように合意に達する必要がありますか？

@jonnyreeves OK、 sinon.configに依存していると言った方が理にかなっています。 サンドボックスを明示的に作成して復元するIMHOは、Sinon 1から来て、 sinon.test何が起こったのか疑問に思っている人々の代替手段としてこれを提供する限り、問題ありません。 だから、文書は次のようなものを読む必要があります

sinon.test

_これはバージョン2で非推奨になり、サンドボックスを明示的に作成することになりました。 link to sandbox参照してください。_

私はバージョン2でよりスリムなAPIを求めているので、 typeOf 、 extends 、 sinon.test*ようなものは、他のNPMモジュールや他の既存の機能によってより適切に提供される可能性があります。

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プロパティに割り当てるだけで、テストに1行余分に含めるだけで、面倒な作業を最小限に抑えることができます。 sinonオブジェクトが（ Object.freeze(sinon) ）ある時点でフリーズしていないことを確認する必要があります...

@jonnyreeves ： sinon.mockに関して@mroderickが2.0がリリースされるまで待ってからこれを削除することを提案したことを覚えています。 すでに非推奨になっていることを通知しているので、2.0リリースのIMHOの後で削除しても問題ありません。 ただし、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.testおよびsinon.testCaseと一緒にsinon.test sinon-testパッケージに移行する方が適している可能性がありますか？

@ fatso83 @mantoni @cjohansen; sinon-testパッケージの動作中のビルドをレビューする準備ができています-空のgitリポジトリをsinonjs/sinon-testで初期化して、PRを上げてください。

ありがとう

早かった！ https://github.com/sinonjs/sinon-test

@cjohansen空のREADMEをプッシュしてください。 現在の状態ではPRを上げることができないようです。

終わり

おかげで、PRが発生しました-フィードバックを歓迎します： https ：

@mroderickどこかにプッシュされた作品がある場合は、私に知らせてください。 私はドキュメントを手伝うことができるかもしれません！

@spinningarrowそれは素晴らしいことです。 残りの作業とは別にこれを追跡するために＃991を作成しました。 私はこれを私の考えで近日中に更新するでしょう、そして私たちはそこからそれを取ることができます。

私たちは時々モックに関連するいくつかの問題を抱えています。 @jonnyreevesが実際にモジュールを抽出するという大変な作業を行ったので、モジュールをリポジトリに移動するのは意味がありませんか？ 次に、モックに関連するすべてのディスカッションをそこに移動し、ここで問題を閉じることができます。 これは主に管理の負担を軽減するためです。

私たちは時々モックに関連するいくつかの問題を抱えています。 @jonnyreevesが実際にモジュールを抽出するという大変な作業を行ったので、モジュールをリポジトリに移動するのは意味がありませんか？ 次に、モックに関連するすべてのディスカッションをそこに移動し、ここで問題を閉じることができます。 これは主に管理の負担を軽減するためです。

これは、そのリポジトリを開発ツールなどと同期させるという管理上の負担も意味します。
おそらく、最初に簡単な共有開発ツールをセットアップする必要がありますか？ cc： @mantoni

@mroderick @ fatso83 OK、2.0をドアから出すことができるかどうか見てみましょう。

この問題の概要を更新して、すべての未解決の移行と見なされるものをカバーしました（これを読んでいる場合は、テストスイートのCJS化を含めてください-ヘルプ！）-ご覧になり、同意する場合はお知らせください傑出した作品。

さらに、私は以下についてコンセンサスを得たいと思います。

1. typeOfとextendをパブリック（ sinon. ）APIから削除する必要がありますか、それとも（私が推測する）APIの最新化を受けるSinon3.xを待つ必要があります。
2. 従来のIEサポート/ハックを2.0から削除する必要がありますか？ これにより、「fakeXDM」コードを削除できるため、移行が簡素化される可能性があります。詳しく調べていないため、この作業をまだ見積もることができません。
3. 新しいドキュメントサイトの出荷は2.0リリースの前提条件ですか？ あまり牽引力がないのではないかと心配です:)

皆さんありがとう。

@jonnyreeves ：あなたは確かに今夜忙しい蜂でした😺。 私の前には長い休暇があるので、テストスイートの優れた移行を確実に手伝うことができます（以下に「しかし」があります）。

あなたのポイントについて：

1. 彼らは行くべきです。 これはほぼ解決したと思いました（上記の概要を参照）。
2. 最初に「レガシーIE」を定義しましょう。 バージョン<10、またはsinon-ieパッケージ全体？ IE9は、XDRと呼ばれる奇妙なCORSの代替手段とともに出荷されていました。 2012年より前にリリースされたIEバージョンのサポートをまだ目指している人がいれば、いつでも1.xブランチを使用できると思います。 XDMで何を参照しているかわかりませんか？ どのブラウザバージョンsinon-ieが必要かわからないので、パッケージが必要ないことについてあまり大げさではありません。 私たちはその結果を確信する必要があります。
3. ドキュメントは今のところ問題点ですが、ここで何を言うべきか少しわかりません。 上記の他のポイントを支援する前に、＃991を掘り下げ始めることができます。 ドキュメントをプッシュする場所があれば、生活が良くなります。

これのステータスが何であるか興味がありますか？ 約6か月前からあまり進歩していないようです。 私は現在、さまざまな理由でプレリリースに依存しています（シンボルサポートの機能は巨大なものです）—プッシュするつもりはありませんが、単純な 'がありますタイムライン '/'まだタイムラインはありません '素晴らしいでしょう！ <3

@ELLIOTTCABLE資金がないため、

1. 上記の「... 2016年7月8日に参照」が表示されていても、リストの最初のコメントがその日付のものであることを意味するだけです。 最新号の＃1235は、これを「12日前」に言及しています。
2. 問題のリストはほぼ完全です-半年前とは異なります。

ですから...私たちはどこかに到達していますが、以前のバージョンのバグ修正を監視し、新しい機能を絶えず提供しているため、メンテナンスに多くの時間を費やしています。 これを調べて書くだけで、最終的には30分かかりました😅

基本的に、上記のリストを確認した後、残っている2つの主要な問題があります。

• 「fake_serverと友達を移行する」（90％解決、残りわずか-上記を参照）。
• Webサイトを公開します（＃1220を参照：1つのマイナーで非常に簡単なものと1つの中程度のタスクを手に入れるために）

上記の他の閉じていないチェックマークのほとんどは、＃1221での議論に基づいて、サポートされないと確信している古いIEリリース（6-10）に関連していると思いますので、無視してかまいません。 今それを扱います。

@ sinonjs / sinon-core：前のコメントで、＃1221の議論に基づいて、完了できない可能性のある上記の問題があることに気づきました。

1. レガシーIEのサポート/回避策を削除しますか？
2. xdomainの修正

とにかく触れない場合は、レガシーIEビットを削除するPRを作成してもかまいませんか？ xdomainは、ほとんどがIEのみのCORSに似たハックだったので、削除できるので、歴史的な埋め立て地にも入る可能性があると思いますか？

@ fatso83ああ、k。 参照されている問題に関する更新されたコメントを見逃しました。 私のためにこれをレビューすることがあなたに役立つことを願っています！

無関係：これの一部はIE6のサポートを放棄しているようです。 それは残念です。 ああ、そうですね、c'est lamarcheduprogrès！ / =

私たちは基本的にそこにいます、ドキュメントサイトには独自の問題があります。

ちょっとチャップス-2.0を「安定した」シノンリリースとしてマークして1.xを殺すのを妨げるものはありますか？ :)

最後に＃1297が欲しかったと思います。

その上でETA？ 来週までに出荷することをお勧めします。出荷されていない場合は、その1つの機能を延期します。

あなたたちは美しいです。 <3