Per https://github.com/wealthfront/sinon-sandbox/issues/7:
In our codebase, we use
import sinon from 'sinon-sandbox', and have a linter rule that forbids importingsinondirectly. However, this means we can't usesinon.assert.
Would you be willing to accept a PR that attaches sinon.assert to sandbox instances?
Maybe you can use sinon.assert.expose to attach it yourself? See http://sinonjs.org/docs/#assertions
@mantoni according to http://sinonjs.org/docs/#assert-expose, that means that the actual sinon.assert API won't be there - ie, sinon.assert.called will become assertCalled - the whole idea is that sinonSandbox.assert has identical methods as sinon.assert :-/
Indeed! Per https://github.com/wealthfront/sinon-sandbox/issues/7#issuecomment-228912571 however, I think it would be better for the upstream to do it - since the sandbox already exposes match, the precedent is there.
Is there a reason that this semver-minor change wouldn't be a good thing?
Fine with me, was just curious. We're going to review the API surface for the 3.0 release and I wouldn't want to introduce anything that doesn't fit with that. Maybe @mroderick or @fatso83 have any feelings?
I just reviewed #1000 (offtopic: we should try and get this ball rolling again) and I could not really see much preventing us from doing this. It is a very minor change AFAIK, and seemingly only aligns the sandbox api with that of the sinon object.
So I am pro.
Submitted #1076
Yay, thanks everyone! Looking forward to the release.
Most helpful comment
I just reviewed #1000 (offtopic: we should try and get this ball rolling again) and I could not really see much preventing us from doing this. It is a very minor change AFAIK, and seemingly only aligns the sandbox api with that of the
sinonobject.So I am pro.