Skip to content
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

Using proxyquire with native dependencies (with .node files) #108

Closed
hsablonniere opened this issue Feb 26, 2016 · 4 comments
Closed

Using proxyquire with native dependencies (with .node files) #108

hsablonniere opened this issue Feb 26, 2016 · 4 comments

Comments

@hsablonniere
Copy link

Hi maintainers 😄

I'm trying to use proxyquire with an app using couchbase. This module has some native dependencies (with .node files).

I have some mocha tests where I don't stub the couchbase module. Because I used @global on some stubs, this trigger the big cache clear, which is exactly what I want.

From the tests I've done, this "clean" seems too agressive. When using mocha in watch mode, the first run goes well and the others fail. It seems that clearing the cache the ways you do here tells Node that he should require the couchebase module again but when he transitively requires the other files and tries to require a .node it throws with this :

Error: Module did not self-register.

You can see the problem with a simple execution of this code :

var Module = require('module');

require('couchbase');

Module._cache = {};

require('couchbase');

// => Error: Module did not self-register.

With a naive cleaning that does not remove the .node files. It does not fail.

var Module = require('module');

require('couchbase');

for (var id in Module._cache) {
    if (!id.match(/.node$/)) {
        delete Module._cache[id];
    }
}

require('couchbase');

// => no error, everything is OK

I'm not sure this would be the best way to fix this problem, so before submiting a PR I wanted your opinion.

Cheers ❤️

@bendrucker
Copy link
Collaborator

Honestly not sure, your solution seems as good as anything I can think of

@hsablonniere
Copy link
Author

OK. I'll try to find out more on have the _cache works and I'll submit a PR 😉

@hsablonniere
Copy link
Author

I found these :

It seems that as of right now, native addons that are Not multi-context ready (which I don't really understand) cannot be unregistered easily.

Since your lib does not allow to stub such native addons, I would say it's OK to only remove stuffs that are not .node.

@hsablonniere
Copy link
Author

Err... I saw in the test suite that you check that .node file can be stubbed. Is it a problem ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants