Currently, sinon is added as a dependency in the package.json. Such package managing causes issues due to two sinon instances running in an end-user project (sinon instance in ts-sinon library and sinon itself in the end-user projects). For example, stubbing class methods using ts-sinon stubConstructor and later on using withArgs(sinon.match(someObject)) function from sinon package does not work correctly due to sinon instances conflicts - methods are not called when they should be. The issue gets fixed when I move this library's code directly to my project and use my sinon instance.
So proposed solution would be to move sinon and its dependencies to peer dependencies list.
Currently, sinon is added as a dependency in the package.json. Such package managing causes issues due to two sinon instances running in an end-user project (sinon instance in ts-sinon library and sinon itself in the end-user projects). For example, stubbing class methods using ts-sinon stubConstructor and later on using withArgs(sinon.match(someObject)) function from sinon package does not work correctly due to sinon instances conflicts - methods are not called when they should be. The issue gets fixed when I move this library's code directly to my project and use my sinon instance.
So proposed solution would be to move sinon and its dependencies to peer dependencies list.