Question: is it possible not to use the magic require call?

[royriojas]

I mean I do understand that in order to get the module in the bundle that call has to exist, but the require call inserted actually executes the code of the module that I want to mock.

A possible solution would be to insert something like this

return '/* proxyquireify injected requires to make browserify include dependencies in the bundle */; (function __magic_name__() { ' +
    requireDeps(deps) + '});';

that way browserify will still include the file in the bundle but not immediately execute it.

That change seems to work with the example/foobar code

Should be possible to do something like that instead of the actual require call? that's currently making some of the tests I have to fail because the code actually try to do a redirection as soon as it start.

[bendrucker]

Definitely possible that a change like you're describing would work and it would definitely be more correct. PR welcome.

[royriojas]

@bendrucker mmm, the unit tests are failing even without any change made by my part... any ideas why?

[royriojas]

I just cloned the repo, and wanted to make the change and ran the tests to verify everything was ok before attempting to make any change and tests fail on 3 tests

npm run test-main

will produce the following output

uninitialized proxyquire
ok 5 throws when proxyquireify was not initialized with require
not ok 6 test exited without ending
  ---
    operator: fail
  ...
not ok 7 test exited without ending
  ---
    operator: fail
  ...
not ok 8 test exited without ending
  ---
    operator: fail
  ...

[royriojas]

It works with previous browserify versions though browserify <= 9...

[royriojas]

so it works until browerify@10.2.4, anything above that make the tests fail...

[bendrucker]

Won't have time to look at it for a few days. If you're still interested and can't figure it out, ping me mid week.

[thlorenz]

require call inserted actually executes the code of the module that I want to mock

That will happen with proxyquire as well unless you use @noCallThru. I'd suggest to put the code that's executing into an init function or so. Executing code during require that changes state is not recommended either way as it may execute more than once depending on your package structure (i.e. if the module is there twice vs. got deduped).

[royriojas]

@thlorenz, I agree with you is best to not have code that autoexecute, but there are couple of instances where I cannot avoid that. And yeah I know I will have to use @noCallThru. Yet letting the code to execute before my mock is injected breaks some tests so that's why I thought it was better to just wrap the require magic and not actually excute it.