Sinon: Ansonsten 2.0 Release

Ich möchte eine neue Dokumentations-Website erstellen, basierend auf der Arbeit, die sich bereits in /docs . Ich hoffe, dass ich in meinem Urlaub nächste Woche einige Stunden damit verbringen kann.

@mroderick Wenn Sie die Arbeit irgendwohin

Die Kontrollkästchen wurden aktualisiert. Ich bin mir nicht sicher, ob "sinon.sandbox migrieren" aktiviert sein soll, aber zumindest ist der PR geschlossen.

@jonnyreeves : nicht sicher, warum wir sinon.test entfernen sollten. Dies ist eine Sandbox um den Test herum, die alle erstellten Stubs bereinigt und nach dem Test automatisch ausspioniert. Das entlastet die Leute von vielen beforeEach und afterEach Funktionen. Sehr nützlich und hat wenig mit dem Testen von Frameworks zu tun.

Benutzer müssten eine einfache Alternative dazu sehen, damit dies zugunsten eines anderen (besseren) entfernt werden kann.

Ich habe sinon.testCase selbst nie benutzt, wahrscheinlich weil seine API zu BusterJS passt (wo jeder Testfall eine Eigenschaft der Testsuite ist) und nicht zu Mocha (wo jeder Test eine anonyme Funktion ist, die im Hauptteil der Testsuite läuft ).

@fatso83 Das Hauptproblem, das ich mit sinon.test ist die Tatsache, dass es auf dem Singleton sinon.config basiert. IMHO Benutzer können viel mehr Kontrolle haben, indem sie eine Sandbox in den beofreEach und afterEach Hooks ihres Test-Frameworks erstellen (und wiederherstellen).

Wenn wir sinon.test (und sinon.testCase ) in der öffentlichen API behalten; dann müssen wir diese beiden Probleme ansprechen - obwohl ich ein langjähriger Benutzer / Support von Sinon bin, bin ich neu im Hacken seines Projekts - wie sollen wir Konsens erreichen?

@jonnyreeves OK, es machte mehr Sinn, als du erwähntest, dass es auf sinon.config basiert . Das explizite Erstellen und Wiederherstellen von Sandboxes ist IMHO in Ordnung, solange wir dies als Alternative für Leute anbieten, die von Sinon 1 kommen und sich fragen, was jemals mit sinon.test passiert ist. Die Dokumentation sollte also etwa lauten wie

sinon.test

_Dies ist in Version 2 veraltet, um explizit eine Sandbox zu erstellen. Siehe link to sandbox ._

Ich bin voll für eine schlankere API in Version 2, also könnten Dinge wie typeOf , extends und sinon.test* von anderen NPM-Modulen oder anderen vorhandenen Funktionen besser bedient werden.

Ich denke, etwas wie npm install sinon-test und var sinonTest = require('sinon-test')(config); könnte ein anständiger Ersatz sein.

:+1: um solche Dienstprogramme in separate npm-Module zu verschieben. Weniger Code im core

Danke für die Eingabe; Ich habe die Übersicht oben aktualisiert, um die bisherige Diskussion widerzuspiegeln (hauptsächlich Fragezeichen entfernen, Aufgaben klarer machen), bitte schauen Sie vorbei.

Könnten wir auch einen ähnlichen Abschluss erhalten für:

• Entfernen von sinon.log und sinon.logError (beide werden vom fake_server verwendet; und würden wahrscheinlich besser als Konfiguration an diese Instanzen weitergegeben)
• Entfernen von sinon.mock aus 2.0

Vielen Dank

Ich habe nie sinon.testCase , aber ich bin ein starker Benutzer von sinon.test . Ich bin damit einverstanden, dass es in eine separate Bibliothek geht, aber um nicht zu vergessen: Es gibt einige Leute, die Test-Frameworks verwenden, die beforeEach per Design (zB Tape) unterstützen, mit dem Argument, dass diese Setup Funktionen führen zu gekoppelten Testfällen. Wir könnten diesen Benutzern viele Probleme bereiten, wenn es keinen einfachen Ersatz gibt.

Ich denke, wir könnten so etwas als Migrationspfad anbieten:

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

@mantoni : Toller Vorschlag. Durch einfaches Zuweisen der jetzt nicht mehr verwendeten Eigenschaft test wird den Benutzern der geringste Aufwand dadurch gegeben, dass nur eine zusätzliche Zeile in ihre Tests aufgenommen wird. Wir müssen nur sicherstellen, dass das Objekt sinon nicht irgendwann eingefroren ist (wie in Object.freeze(sinon) ) ...

@jonnyreeves : bezüglich sinon.mock Ich erinnere mich, dass @mroderick vorgeschlagen hat, zu warten, bis 2.0 veröffentlicht wurde, bevor man dies entfernt. Wir haben bereits seit einiger Zeit signalisiert, dass es veraltet ist, daher sollte es in Ordnung sein, es nach dem Release 2.0 IMHO zu entfernen. Aber da wir bereits CommonJS-Unterstützung haben, würde ich es gerne vor der Version 2.0 entfernen, _wenn_ wir den Code in ein eigenes Modul extrahiert haben. Dann könnten die Leute einfach let sinon.mock = require('sinon-mock') , wenn sie so zufrieden waren.

Was sinon.log* , sehe ich keinen Grund, an ihnen als öffentliche Funktionen festzuhalten, wenn wir sie bei Bedarf nur als Konfiguration bereitstellen könnten.

WRT berücksichtigt sinon-test , beachten Sie nur, dass wir den Verbrauchern erlauben müssten, eine Konfiguration bereitzustellen, dh:

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

oder ähnliches.

Habe gerade eine weitere mögliche API-Änderung beim Erstellen eines sinon-test Pakets entdeckt; Haben Sie eine Idee, was mit sinon.assert passieren soll? Auch dies fühlt sich für mich nicht wie ein Kernelement der sinon-API an und ist möglicherweise besser geeignet, wenn Sie neben sinon.test und sinon.testCase zu einem sinon-test Paket migrieren?

@fatso83 @mantoni @cjohansen; Ich habe einen funktionierenden Build eines sinon-test Pakets zur Überprüfung bereit - könnte einer von euch bitte ein leeres Git-Repo bei sinonjs/sinon-test initialisieren, damit ich bitte eine PR dagegen erheben kann?

Vielen Dank

Das war schnell! https://github.com/sinonjs/sinon-test

@cjohansen könntest du bitte einfach eine leere README dazu schieben? Sieht so aus, als ob ich im aktuellen Zustand keine PR erstellen kann.

Fertig

Danke, PR angehoben - Feedback willkommen: https://github.com/sinonjs/sinon-test/pull/1

@mroderick Wenn Sie die Arbeit irgendwohin

@spinningarrow das wäre toll. Ich habe #991 erstellt, um dies getrennt vom Rest des Aufwands zu verfolgen. Ich werde dies in den kommenden Tagen mit meinen Gedanken aktualisieren, und wir können es von dort aus übernehmen.

Wir haben hin und wieder ein paar Probleme in Bezug auf Mocks. Nun, da @jonnyreeves die harte Arbeit

Wir haben hin und wieder ein paar Probleme in Bezug auf Mocks. Nun, da @jonnyreeves die harte Arbeit

Dies würde auch den Verwaltungsaufwand bedeuten, dieses Repository mit Entwicklungstools usw. synchron zu halten.
Vielleicht sollten wir zuerst sicherstellen, dass wir einfache gemeinsame Entwicklungstools einrichten? cc: @mantoni

@mroderick @fatso83 OK, mal sehen, ob wir 2.0 aus der Tür bekommen.

Ich habe die Übersicht dieser Ausgabe aktualisiert, um alle meiner Meinung nach ausstehenden Migrationen abzudecken (einschließlich der CJSification der Testsuite bitte, wenn Sie dies lesen - Hilfe!) - bitte schauen Sie nach und lassen Sie es mich wissen, wenn Sie damit einverstanden sind die herausragende Arbeit.

Darüber hinaus möchte ich in folgenden Punkten Konsens erzielen:

1. Sollten wir typeOf und extend aus der öffentlichen ( sinon. ) API entfernen, oder sollte dies auf Sinon 3.x warten, das (ich nehme an) eine Modernisierung der API durchlaufen wird? .
2. Sollten wir die Legacy-IE-Unterstützung/Hacks aus 2.0 entfernen? Dies _kann_ die Migration vereinfachen, da wir den 'fakeXDM'-Code fallen lassen könnten - ich habe nicht genau hingeschaut und kann diese Arbeit noch nicht wirklich einschätzen.
3. Ist der Versand der neuen Docs-Site eine Voraussetzung für die Version 2.0? Ich mache mir Sorgen, dass es nicht viel Traktion hat :)

Danke an alle.

@jonnyreeves : Du warst heute Abend sicherlich eine fleißige Biene 😺. Ich habe einen langen Urlaub vor mir, daher konnte ich bei den noch ausstehenden Migrationen der Testsuite sicherlich helfen (ein "aber" gibt es weiter unten).

Zu deinen Punkten:

1. Sie sollten gehen. Ich dachte, das wäre so ziemlich erledigt (siehe die Übersicht oben).
2. Lassen Sie uns einfach zuerst "Legacy IE" definieren. Versionen < 10 oder das gesamte sinon-ie Paket? IE9 wurde immer noch mit einer seltsamen CORS-Alternative namens XDR ausgeliefert. Wenn es jemanden gibt, der immer noch darauf abzielt, IE-Versionen zu unterstützen, die vor 2012 veröffentlicht wurden, könnte er immer den 1.x-Zweig verwenden, denke ich. Sie sind sich nicht sicher, worauf Sie sich mit XDM beziehen? Ich bin mir nicht sicher, für welche Browserversionen sinon-ie benötigt wird, daher kann ich nicht zu bombastisch sein, dass das Paket nicht benötigt wird. Wir sollten uns der Konsequenzen sicher sein.
3. Die Dokumentation _ist_ im Moment ein Problem, aber ich bin mir ein bisschen unsicher, was ich hier sagen soll. Ich könnte anfangen, mich mit #991 zu beschäftigen, bevor ich bei den anderen oben genannten Punkten helfe. Einen Ort zum Verschieben von Dokumenten zu haben, würde das Leben verbessern.

Neugierig, wie der Status dazu ist? Es sieht nicht so aus, als ob es seit ~6 Monaten viel Fortschritt gegeben hätte; Ich bin derzeit aus verschiedenen Gründen auf eine Vorabversion angewiesen (die funktionierende Symbolunterstützung ist ein enormer) - ich möchte nicht pushen, aber ein einfaches "es gibt ein"timeline' / 'es gibt noch keine timeline' wäre toll! <3

@ELLIOTTCABLE da wir keine Finanzierung haben, gibt es keinen

1. Auch wenn Sie oben "... referenziert am 8. Juli 2016" sehen, bedeutet dies nur, dass der erste Kommentar in der Liste von diesem Datum stammt. Die neueste Ausgabe, Nr. 1235, verwies darauf "vor 12 Tagen".
2. Die Liste der Themen ist fast vollständig – anders als noch vor einem halben Jahr.

Also ... wir kommen schon etwas voran, aber die Überwachung von Fehlerbehebungen für die vorherige Version sowie die ständige Bereitstellung neuer Funktionen verschlingen viel unserer Wartungszeit. Allein das Recherchieren und Schreiben hat am Ende eine halbe Stunde gedauert 😅

Grundsätzlich bleiben nach Durchsicht der obigen Liste nur noch zwei Hauptprobleme:

• "Fake_server und Freunde migrieren" (90% gelöst, nur noch ein bisschen übrig - siehe oben).
• Veröffentlichen Sie die Website (siehe Nr. 1220: eine kleine, supereinfache Sache und eine mittlere Aufgabe zu gewinnen)

Ich denke, die meisten der anderen oben genannten Häkchen zum Aufschließen beziehen sich auf alte IE-Releases (6-10), von denen ich mir ziemlich sicher bin, dass sie aufgrund der Diskussionen in #1221 nicht unterstützt werden, sodass sie ignoriert werden können. Werde das jetzt ansprechen.

@sinonjs/sinon-core: Der vorherige Kommentar hat mich darauf aufmerksam gemacht, dass wir oben einige Probleme haben, die wir basierend auf der Diskussion in #1221 wahrscheinlich nicht abschließen werden:

1. Legacy-IE-Unterstützung / Problemumgehungen entfernen?
2. xdomain reparieren

Ist es egal, ob ich einen PR erstelle, um nur die Legacy-IE-Bits zu entfernen, wenn wir sie sowieso nicht berühren? Ich würde annehmen, dass xdomain auch auf der historischen Mülldeponie landen kann, da dies hauptsächlich ein IE-only CORS-ähnlicher Hack war, also kann er entfernt werden?

@fatso83 Ahhhh, k. Ich habe die aktualisierten Kommentare zu den referenzierten Problemen verpasst. Ich hoffe, die Rezension für mich hat Ihnen geholfen!

Unabhängig davon: Es sieht so aus, als würde ein Teil davon die Unterstützung für IE6 aufgeben. Das ist bedauerlich. Na gut, c'est la marche du progrès! /=

Wir sind im Grunde da, die Docs-Site hat ihr eigenes Problem.

Hey Leute - hindert uns etwas daran, 2.0 als "stabile" Sinon-Version zu markieren und 1.x zu töten? :)

Denke, wir wollten #1297 als letztes.

ETA dazu? Ich schlage vor, dass wir spätestens nächste Woche versenden und dieses eine Feature verschieben, wenn es nicht fertig ist.

Ihr seid schön. <3