Helper library for creating final stubs for proxyquire. Used to remove some pain from mocking imports/requires in unit tests.
usage: npm i resolvequire remember – npm package name must be in lower case
About Proxyquire and Resolvequire.
Proxyquire just proxies nodejs's require in order to make overriding dependencies during testing. But it is quite old and having some interface limitations.
The way to extend Proxyquire abilities - proxyquire-2. The way to enable webpack aliases - proxyquire-webpack-alias or this - resolvequire. I can recommend using proxyquire-2 instead of proxyquire as long in includes some features proxyquire decide not to contain.
- withRelativeResolve - to use stubs from some subset of paths
- withAliasResolve - to enable webpack alias name resolving
- withRelativeFileName - to enable same for mocking file
- withAliasInFileName - to enable same for mocking file
- setWebpackConfig - to set non-default webpack confug
- withIndirectUsage - to enable indirect usage of Proxyquire,
- withAllStubsUsed - to be sure that you write all stubs with out mistakes. So all you write were used.
- overrideEntryPoint - to override entry point
const resolvequire =);resolvequire;
Why you should use withAllStubsUsed?
Lets imagine you have a file
And it requires it sibling
And you have alias
Long story short, you will just write
Resolvequire will transform this name into
./common, but webpack may transform it into
../helpers/common (dunno why).
Stub will not be mocked. withAllStubsUsed will throw error. You need that error.
Or just use proxyquire-webpack-alias - it has no issues with this.
how you normally use proxyquire?
You use it
How you can use resolvequire?
;;const myProxyquire = ;
3 lines in each file :( A bit ugly? Better to crete a little module, to hide some magic. But you cannot use Proxyquire from other file, or it will be unable to find target file to mock. (just try)
How to use resolvequire?
//test/proxyquire.js - lets create a little helper, in _different_ dirrectory; // we need Proxyquire base class;// then you will call proxyquire.load(filename) - it will try find filename in THIS dirrectory.// THIS == this module, not source test, which requires this helper.// one should override entry point.// override entry point. Defaults to `parent` module -> our test.;// create new proxyquire instance.const withIndirect = ;// add magicsconst myProxyquire = ;// export it;
It is an open question - should I ship this helper, or not.
Stop! What is this for?
For example, you have a file
But then, after babel for example, it will become
var module1 = ; // localvar module2 = ; // localvar module3 = ; // *babeled* to new locationvar lib = ; // node_modulevar helper1 = ; // found in project root
Next you have 100500 files, all having same deps, and you want your unit tests to mock every dependency they have.
var mockedModule = proxyquire;
For you - all files have same dependencies. But all files lays in different locations, and
actual requires will be different.
For mocking you can use proxyquire, but in every case you have to provide extract stubs to overwrite. All your files can import modules in same maner, but in final code all requires will be relative to a file. Let me repeat - they all will be different. They all will require different setup for proxyquire.
var mockedModule =
And I will search all listed paths and calculate correct stubs.
var mockedModule =
And I will calculate correct stubs using webpack aliases.
One command, and it will works.
resolveQuire will try to find form of a fileName, that will be used by target file. It will also make a twin for keys like 'module' -> 'module.js'. And nodejs require do.
It just work. Work absolutely not perfect, cos it is very hard to
invent names of files requires.
PS: PR-148, or https://github.com/theKashey/proxyquire works from opposite direction - it overloads proxyquire resolve logic, and tries to find a match between known require and know stub key. No place for 'inventions'. But a good place for RegEx or straight logic. Might work more stable and in a better way.