Sinon: Sinon 2.0 Release

I would like to create a new documentation website, based on the work that is already in /docs. I am hoping to spend some hours on that during my vacation next week.

@mroderick If you have the work pushed somewhere, let me know. I might be able to help with the docs!

Updated the checkboxes. Not sure if "Migrate sinon.sandbox" should be checked, but at least the PR is closed.

@jonnyreeves : not sure why we should remove sinon.test. This is a sandbox around the test that cleans any created stubs and spys up automatically after the test. That alleviates people from lots of beforeEach and afterEach functions. Very useful, and has little to do with testing frameworks.

Users would need to see an easy alternative to this for this to be removed in favor of something else (better).

I have never used sinon.testCase myself, probably because its api fits BusterJS (where each test case is a property of the test suite) and not Mocha (where each test is an anonymous function running in the body of the test suite).

@fatso83 The main issue I have with sinon.test is the fact that it relies on the sinon.config singleton. IMHO Users can have far more control by creating (and restoring) a sandbox in their test-framework's beofreEach and afterEach hooks.

If we are going to keep sinon.test (and sinon.testCase) in the public API; then we need to address both of these issues - although a long time user / support of sinon, I'm new to hacking ont his project - how should we reach concensous?

@jonnyreeves OK, it made more sense when you mentioned it relied on sinon.config. IMHO explicitly creating and restoring sandboxes is fine as long as we supply this as an alternative for people coming from Sinon 1 and wondering what ever happened to sinon.test. So the doucmentation should read something like

sinon.test

_This has been deprecated in version 2 in favor of explictly creating a sandboxe. See link to sandbox._

I am all in for a leaner API in version 2, so stuff like typeOf, extends and sinon.test* could be better served by other NPM modules or other existing functionality.

I think something like npm install sinon-test and var sinonTest = require('sinon-test')(config); could be a decent replacement.

:+1: to moving utilities like this into separate npm modules. Less code in the core

Thanks for the input; I've updated the overview up top to reflect the discussion so far (mainly removing question marks, making tasks clearer), please take a look.

Also, could we get similar closure on:

• removing sinon.log and sinon.logError (both are used by the fake_server; and would probably be better passed as configuration to those instances)
• removing sinon.mock from 2.0

Thanks

I never used sinon.testCase, however I'm a heavy user of sinon.test. I'm fine with it going into a separate library, but just to not forget: there are quite a few people using test frameworks that don't support beforeEach by design (e.g. tape) with the argument that these setup functions lead to coupled test cases. We might cause a lot of problems for these users if there's no simple to drop-in replacement.

I guess we could offer something like this as a migration path:

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

@mantoni : Great suggestion. By just assigning to the the now unused test property it gives people the least amount of hassle by just including one extra line in their tests. We just have to make sure that the sinon object is not frozen (as in Object.freeze(sinon)) at some point ...

@jonnyreeves : regarding sinon.mock I remember that @mroderick suggested to wait until 2.0 was released before removing this. We have already signaled for some time that it has been deprecated, so it should be fine to remove it after the 2.0 release IMHO. But since we already have CommonJS support I would not mind removing it before the 2.0 release _if_ we have extracted the code into a module of its own. Then people could just let sinon.mock = require('sinon-mock'), if they so pleased.

Regarding sinon.log*, I see no reason to cling on to them as public features if we could just supply them as configuration when needed.

WRT factoring out a sinon-test, just note that we would need to allow consumers to supply a configuration, ie:

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

or similar.

Just spotted another possible API change whilst creating a sinon-test package; any thoughts as to what should happen to sinon.assert? Again this doesn't feel like a core part of the sinon API to me and may be better suited by migrating to a sinon-test package alongside sinon.test and sinon.testCase?

@fatso83 @mantoni @cjohansen; I've got a working build of a sinon-test package ready for review - could one of you please initialise an empty git repo over at sinonjs/sinon-test so I can raise a PR against it please?

Thanks

That was quick! https://github.com/sinonjs/sinon-test

@cjohansen could you just push an empty README to it please? Looks like I can't raise a PR in the current state.

Done

Thanks, PR raised - feedback welcome: https://github.com/sinonjs/sinon-test/pull/1

@mroderick If you have the work pushed somewhere, let me know. I might be able to help with the docs!

@spinningarrow that would be great. I have created #991 to track this separately from the rest of the effort. I'll be updating this in upcoming days with my thoughts, and we can take it from there.

We are having a few issues every now and then relating to mocks. Now that @jonnyreeves has done the hard work of actually extracting the module, would it not make sense to move the module into a repo if its own? Then we could just move all discussions relating to mocks there, and close the issues here. This is mainly just to ease the administration burden.

We are having a few issues every now and then relating to mocks. Now that @jonnyreeves has done the hard work of actually extracting the module, would it not make sense to move the module into a repo if its own? Then we could just move all discussions relating to mocks there, and close the issues here. This is mainly just to ease the administration burden.

That would also mean administration burden of keeping that repository in sync with dev tools, etc.
Perhaps we should make sure we have easy shared dev tools set up first? cc: @mantoni

@mroderick @fatso83 OK, let's see if we can get 2.0 out the door.

I've updated the overview of this Issue to cover what I consider to be all outstanding migrations (including CJSification of the testsuite, please, if you are reading this - help!) - please take a look and let me know if you agree with the outstanding work.

Additionally, I would like to get consensus on the following:

1. Should we remove typeOf and extend from the public (sinon.) API, or should this wait for Sinon 3.x which (I assume) will undergo a modernisation of the API.
2. Should we remove the legacy IE support/hacks from 2.0? This _may_ simplify the migration as we could drop the 'fakeXDM' code - I haven't looked closely so I can't really estimate this work yet.
3. Is shipping the new docs site a prerequisite of the 2.0 release? I'm concerned that it doesn't have a lot of traction :)

Thanks all.

@jonnyreeves: You have certainly been a busy bee tonight 😺. I have a long vacation ahead of me, so I could certainly help with the outstanding migrations of the test suite (there is a "but" below).

Regarding your points:

1. They should go. I thought this was pretty much settled (ref, the overview above).
2. Let's just define "legacy IE" first. Versions < 10, or the entire sinon-ie package? IE9 was still shipping with some weird CORS alternative called XDR. If there are anyone still aiming to support IE versions released before 2012 they could always use the 1.x branch, I guess. Not sure what you refer to by XDM? I am not sure for which browser versions sinon-ie is needed, so I cannot be too bombastic about the package not being needed. We should be certain of the consequences.
3. Documentation _is_ a pain point right now, but I am a bit unsure of what to say here. I could start digging into #991 before helping with the other points above. Having somewhere to push docs would make life better.

Curious what the status on this is? Doesn't look like there's been much progress since ~6mo ago; I'm currently depending on a pre-release for various reasons (functioning Symbol support being a huge one) — I don't mean to push, but a simple ‘there is a timeline’ / ‘there is no timeline as of yet’ would be great! <3

@ELLIOTTCABLE as we don't have funding, there is no set time line. It progresses as we in the maintainer group - or other volunteers such as yourself - have time to work on the list above. That being said, I think you could have answered the "status" bit yourself if you bothered to poke around a bit more 😉:

1. Even though you see "... referenced on 8 Jul 2016" above, that only means that the first comment in the list is from that date. The latest issue, #1235, referenced this "12 days ago".
2. The list of issues is near-complete - unlike half a year ago.

So ... we are getting somewhere, but overseeing bug fixes for the previous version, as well as a constant supply of new features, suck up a lot of our maintenance time. Just researching and writing this took half an hour in the end 😅

Basically, after looking over the list above there are just two main issues that remain:

• "Migrate fake_server and friends" (90% resolved, just a little bit left - see above).
• Publish the website (see #1220: one minor, super-easy thing and one medium task up for grabs)

I think most of the other uncloses checkmarks above relate to old IE releases (6-10) which I am quite certain will not be supported, based upon the discussions in #1221, so they can be ignored. Will address that now.

@sinonjs/sinon-core: the previous comment made me aware that we have some issues above that we are not likely to complete based on the discussion in #1221:

1. Remove Legacy IE support / workarounds?
2. Fixing xdomain

Care if I create a PR to just remove the legacy IE bits if we won't touch them anyhow? I would assume xdomain can end up in the historical land fill as well, as that was mostly an IE-only CORS-alike hack, so it can be removed?

@fatso83 Ahhhh, k. I missed the updated comments on the referenced Issues. I hope reviewing this for me was of use to you!

Unrelatedly: Looks like part of this is abandoning support for IE6. That's unfortunate. Ah well, c'est la marche du progrès! /=

We're basically there, the docs site has its own issue.

Hey chaps - anything preventing us from marking 2.0 as the "stable" sinon release and killing 1.x? :)

Think we wanted #1297 in as the last thing.

ETA on that? I suggest we ship no later than next week, postponing that one feature if it's not done.

You guys are beautiful. <3