👍

without this, rewire fails when running code with wallaby.js

cc @ArtemGovorov

@jhnns Can this get some love?

Mhmm I'm not sure... @boneskull

In your example, wouldn't redefining __get__ or __set__ destroy the original getters and setters on the exported dependency? It looks like a small change, but I'm afraid that it might lead to subtle bugs when setters and getters are overwritten.

Usually, rewire() should always return a fresh instance, so you would not have this kind of problem. It becomes a problem because people started to re-implement rewire() for other environments only to some extent.

It becomes a problem because people started to re-implement rewire() for other environments only to some extent.

@jhnns From your comments it seems like there is some misunderstanding between how all of our different rewire based packages work.

Your modules rewire and rewire-weback have the same use case. You can call rewire instead of require and then have access to the rewire methods.

rewireify, rewire-global, and babel-plugin-rewire have a slightly different usage pattern. Instead of explicitly calling rewire to add those methods, these modules add the functions to every module that is required via the standard require function. One reason to do this is to use the rewire functionality with proxyquire which also requires the user to use a different function than require. There are many other reasons as well.

So I think all of the module authors want us to all have the same API once rewire is enabled for a module, but we have different requirements for how rewire is injected into a module. In order for our modules to all be closer to rewire core, rewire-core needs to support both function injection patterns. I'm open to suggestions as to how you propose we get there.

@jhnns regardless, rewire fails to work when run under wallaby due to this problem.

@ArtemGovorov could probably provided more accurate information if asked, but I think what's happening is:

1. The user changes a test suite.
2. The test suite is reloaded (rerun).
3. The rewired module does not get reloaded (this partially accounts for the speed with which wallaby reruns tests).
4. Result: The rewired module has already been patched by rewire, and cannot be patched again due to writable's default of false.

Unless it can be shown that setting writable to true actually causes a problem, this sounds a bit like FUD.

In case you disagree on philosophical grounds, I'm of the opinion that the responsibility of a JS library ends once it has done what it was intended to do. It is not necessary for any library to prevent a consumer from augmenting its functionality thereafter, except in rare circumstances. Perhaps this is especially so for rewire, which is intended to be run in test and augments its consumers' module(s)? If JS didn't allow this behavior by nature, rewire probably wouldn't even exist.

(FWIW, babel-plugin-rewire accepted a PR of mine to address this very issue.)

@boneskull You've described it pretty accurately for babel-plugin-rewire. However, I don't remember anyone reporting issues with using rewire itself in wallaby.js. If it does fail, then it's probably for the same reason. If there's some sample I could run to reproduce the issue with rewire itself, I could provide a detailed overview of what is happening.

@ArtemGovorov I don't have one handy, but I can provide an example if it crops up again

@TheSavior that are all valid points. Maybe we should change the way how rewire() works. Maybe that's more pragmatically...

I'm just not happy that there are so many modules that do it "almost" the rewire way, because it can behave very differently in certain situations. It's just too much confusion for beginners.

Concerning this PR: I'm not quite sure... maybe I'll merge this PR as a quickfix. But it's not ideal because it obscures a conceptional problem underneath.

@jhnns, I too am unhappy that rewire, rewireify, rewire-global, and babel-plugin-rewire are all slightly different. That is part of why I've been starting the discussions about how to make them all have the same api. This PR is a requirement that is blocking rewireify and rewire-global from using the same modules as rewire and thus having more shared functionality.

I think we want the same things here.