proxyquire read-only error

[jccguimaraes]

Hey!

Once again thank you for this awesome package.
Unfortunately I am having difficulties using proxyquire :(

Use case:

// lib/package.js
import Database from './services/database';

// ...

// spec/package.spec.js
const proxyquire = require('proxyquire');
const Package = proxyquire(testquire('package', false), {
  './services/database': {}
});

// ...

Output

TypeError: Cannot assign to read only property '.js' of object '#<Object>'

Any thoughts?

[jccguimaraes]

Well, this is actually to do with proxyquire beeing only valid with require which is obviously...

[cgalvarez]

Hi @jccguimaraes !

Could you please include the full error trace to see the calls and the exact line/file which throws the error? Have you tried testquireing the file with a relative path. i.e. testquire('./package', false)?

If you have your code in your package repo I could give it a local test 😉

EDIT:

Well, this is actually to do with proxyquire beeing only valid with require which is obviously...

When you write testquire(relPath, false) the function should return the path to the instrumented files, so requiring your dependency with import ... should not be an issue. Don't know if your refer to that.

[jccguimaraes]

hey @cgalvarez,

I have a branch called dev which is almost up to date development (it does not have the proxyquire though)

I have been digging and this is proxyquire issue as the keyword import is not related with require and is what is causing that issue.

I have tested in many ways, but i could be missing something.

Babel (import) and classes aren't the best mix to deal in proxyquire, I have switched to sinon stubbing.

reference thlorenz/proxyquire#172

[cgalvarez]

@jccguimaraes I'll take a look at this soon. Thank you very much for your explanation and glad to hear that you could circumvent it with sinon stubbing!

[jccguimaraes]

I actually can't really stub 100% dependency (with sinon) :( as this is also a class and I have code in the constructor.

So this is annoying :(

Have you had success using proxyquire with babel?

[cgalvarez]

I've been digging into the code of my projects package (which I had to leave in the background), and I've found no unit test using proxyquire.

Could you push a new branch to your project with your unit test which should work? I think I could clone it locally to trace what's happening here.

[jccguimaraes]

have a look at https://github.com/jccguimaraes/project-viewer-plus/tree/proxyquire

spec/package-spec.js
npm t it will hang

[cgalvarez]

@jccguimaraes Having a look to this now.

1. testquire('package', false) returns ../coverage/.instrumented/package, which is the relative path to the instrumented file, which is the result of applying all babel plugins, so no import inside and that should not be an issue.
2. Looking into the babelified, instrumented file, I can see the keyword class is still inside. I thought it could be the problem, so installed and configured the babel plugin transform-es2015-classes to transform it. Still hanging.

Definitely it's an issue with proxyquire. It hangs when proxyquire tries to override the require's extension handler for .js on this line. To be honest, I don't know why this happens and how to workaround this right now... Maybe it has to do with the NodeJS version embedded inside Atom, which I suppose it is used to run tests.

EDIT: As I was suspecting, the require.extensions object is read-only, and an uncatched exception is being thrown on that line when trying to override the handler. The exception message is TypeError: Cannot assign to read only property '.js' of object '#<Object>'. This could be circumvented by overriding with Object.defineProperty(), but now hangs somewhere else. I'll try to take a look at this again next weeken, quite busy right now and it's likely that I'll have to dig deep into proxyquire code and make a PR to that project.

[jccguimaraes]

@cgalvarez thanks for this troubleshooting.
I really appreciate! Whenever you have the time, don't worry