-
-
Notifications
You must be signed in to change notification settings - Fork 771
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stubbing default exported functions #1623
Comments
Sinon.JS does not concern itself with module systems. I am closing this. Because of the many requests that keep coming in, and that the stewards of the project also write tests for a living, we have published How To Use Link Seams With CommonJS. Please help us keep the issues list manageable and ask usage questions on the Sinon.JS users mailinglist or StackOverflow. Both are good resources where the wider audience of users can offer help. |
Ref #1711 and #1623 for background. This feature is simply about throwing a meaningful error, instead one that tells the user that the property cannot be deleted. As the exports from ECMAScript modules are immutable once created we cannot do anything about them from the view of Sinon, so it's preferable to simply tell the user that when we can. This should not affect transpiled code (say, using Babel), as the resulting modules are no longer true ECMAScript modules (but rather some form of CommonJS module).
Ref #1711 and #1623 for background. This feature is simply about throwing a meaningful error, instead one that tells the user that the property cannot be deleted. As the exports from ECMAScript modules are immutable once created we cannot do anything about them from the view of Sinon, so it's preferable to simply tell the user that when we can. This should not affect transpiled code (say, using Babel), as the resulting modules are no longer true ECMAScript modules (but rather some form of CommonJS module).
@sebakerckhof checkout this #562 (comment) |
Ref sinonjs#1711 and sinonjs#1623 for background. This feature is simply about throwing a meaningful error, instead one that tells the user that the property cannot be deleted. As the exports from ECMAScript modules are immutable once created we cannot do anything about them from the view of Sinon, so it's preferable to simply tell the user that when we can. This should not affect transpiled code (say, using Babel), as the resulting modules are no longer true ECMAScript modules (but rather some form of CommonJS module).
It is a common use case to mock ES modules.
e.g. I have a module that imports getEventByEventId
In my test I want to mock getEventByEventId, e.g.
This was asked before here: #1358 . But this got unrightly closed as a duplicate of: #1121 , while it is a totally different issue.
This was already mentioned in that issue, but it doesn't seem to get looked after anymore.
The text was updated successfully, but these errors were encountered: