npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

resolvequire

v2.0.6

Published

Tool for proxyquire, will help a bit

Downloads

21

Readme

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.

#API

  • 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

#Example

  const resolvequire =
      withAliasInFileName(
        withAliasResolve(
          withAllStubsUsed( 
            proxyquire)
          )
        )
      );
  
   resolvequire.load('alias/helper/foo',{ 'alias/module/bar':{} });   

#Why you should use withAllStubsUsed? Lets imagine you have a file -> /app/helpers/special.js And it requires it sibling -> /app/helpers/common.js And you have alias app. Long story short, you will just write

import something from 'app/helpers/common'

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.

#Entry point how you normally use proxyquire?

import proxyquire from 'proxyquire'

You use it directly. How you can use resolvequire?

import proxyquire from 'proxyquire';
import { withAliasResolve } from 'resolvequire';
const myProxyquire = withAliasResolve(proxyquire);

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
import Proxyquire from 'proxyquire/lib/proxyquire';  // we need Proxyquire base class
import { withAliasResolve, withIndirectUsage, overrideEntryPoint}  from 'resolvequire';

// 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.
overrideEntryPoint(); 

// create new proxyquire instance.
const withIndirect = withIndirectUsage(Proxyquire);
// add magics
const myProxyquire = withAliasResolve(proxyquire);
// export it
export default myProxyquire;

It is an open question - should I ship this helper, or not.

Stop! What is this for?

For example, you have a file

import module1 from "./module1"
import module2 from "./module2.js"
import module3 from "common/module3.js"
import lib1 from "lib1"
import helper1 from "stuff/helper1"

But then, after babel for example, it will become

var module1 = require("./module1.js"); // local
var module2 = require("./module2.js"); // local
var module3 = require("../../../common/module3.js"); // *babeled* to new location
var lib = require("lib1"); // node_module
var helper1 = require("stuff/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.load('../moduleN.js',{
  './module1.js':{}, // will not passs
  './module2':{}, // will not pass
  'common/module3.js':{}, // will not pass
  'lib1':{}, // this will pass :P
  'stuff/module4.js':{}, // will not pass
 });

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 = withRelativeResolve(proxyquire,['../moduleN.js',PROJECTROOT+'/core']).load({
   /*stubsInAnyForm*/
 })

And I will search all listed paths and calculate correct stubs.

Or

 var mockedModule = withAliasResolve(proxyquire).load({
   'core/reducer:'....
 })

And I will calculate correct stubs using webpack aliases.

One command, and it will works.

How?

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.