Mocking ES6 module dependencies


Hello Meteor Forums,

I’ve been trying to mock module dependencies with known require Npm override packages to no avail.

I would prefer this route as opposed to using dependency injection in my modules which would require a big rewrite of most of them and changes in my coding style.

This is a list of some packages I tried:
"mock-require": "^3.0.1", "mockery": "^2.1.0", "proxyquire": "^1.8.0", "rewire": "^3.0.2", "rewiremock": "^3.4.2",

When using them either dependencies have not been mocked or the modules depended on could not be found when using relative paths while trying to mock them.

They weren’t even external dependencies just other modules I wrote which I imported to the module under test with an absolute (meteor) path similar to import moduleDependency from '/imports/api/<moduleDependencyPath>'

When using these absolute meteor paths the mocking would never work. And when trying to use relative paths the modules depended on would not be found to be mocked.

I am aware my ES6 imports are being transformed to CommonJS modules with Babel but I don’t know how this would affect the path which has to be provided to be overridden.

I am aware that most of these packages stress that they require the path provided to be overridden has to be relative to the module under test.

Has anyone been successful in using any of these packages or similar to mock dependecies of modules they are testing with meteor test?

Just fyi I am currently on version and I don’t know if 1.6.1 would offer any benefits with Babel 7.

If anyone made it this far, thanks for reading! :slight_smile:


Hey, did you ever find a solution to this?
I’m just trying to figure it out now


I think mocking dependencies is a bad idea, try thinking in dependency injection style:


import { Dispatcher } from 'core/events';
import ItemServiceModel from './ItemServiceModel';

export const ItemService = new ItemServiceModel({
  dispatcher: Dispatcher,
// @flow

type Inject = {
  dispatcher: any,

 * Item Service
export default class ItemServiceModel {
  dispatcher: any;

   * @param injection
  constructor(injection: Inject) {
    Object.assign(this, injection);

  create(userId: string, data: Object) {
    return userId;


This looks more like implementation injection than anything!

Anywhere I can read up about this pattern?


The idea behind it is straightforward, everything your service uses, gets injected via constructor, or a setter, or property, it doesn’t depend on modules (but it may depend on interfaces), and you instantiate your service elsewhere with the proper dependencies, this lets you properly test your Service, by instantiating and injecting your mocks in the test, and not relying on imports.

Read more here:


Thanks for your tips @diaconutheodor, as stated I dislike DI because it would require me to rewrite most of my modules.

I have not found a working approach for me and therefore would hugely appreciate anyone with an alternative approach to mocking dependencies or dependency injection.

Thank you.


Thankfully I can afford refactoring as recommended by meteor-tuts. Certainly makes isolation a lot easier

I’ve had success mocking some things with sinon and jest in other projects. Have you tried mocking a dependency with one of those?


@coagmano yes I had success with mocking Meteor with jest, but then I went with DI because it just felt cleaner. You’ll have to do some digging but it’s possible, I know I did it.