When injecting a falsey export, it shouldn't fall back to real module

[Aaronius]

In one of my tests, I wish to inject an falsey export. That is, I want to see what module A does when it requires module B and module B exports undefined, null, or false. Unfortunately, inject-loader outputs something like this:

var visitorIdInstance = (injections['../sharedModules/mcidInstance'] || __webpack_require__(47));

Given that the injection is falsey, it doesn't use my injection and instead uses the real module which makes my test useless.

[Aaronius]

@plasticine would you be open to a PR for this? I'm thinking of changing this line:

inject-loader/index.js

Line 55 in 14d573a

src.replace(regex, "(injections[$1] || $&)"),

src.replace(regex, "(injections[$1] || $&)"),

to something like:

src.replace(regex, "(injections.hasOwnProperty($1) ? injections[$1] : $&)"),

[Aaronius]

@plasticine I could really use this, but it was released as part of 3.x which is blocked due to #18. How can we help? Do you need a PR or something?

[Aaronius]

@plasticine this is broken again in 3.x. The output in 3.x looks like:

...
	  function __getInjection(dependency) {
	    return __injections.hasOwnProperty(dependency) ? __injections[dependency] : null;
	  }

	  (function () {
	    var mcidInstance = __getInjection("../sharedModules/mcidInstance") || __webpack_require__(4); /**
...

So even though __getInjection returns null, || __webpack_require__(4); overrides it anyway.

[plasticine]

@Aaronius Hrm—yeah looks like we might’ve regressed this in the re-write to using Babel to parse modules, which happened in 3.x.

Could I get you to raise a new issue and I’ll try and tackle it soon.

[Aaronius]

Sure! If I get a moment I might try tackling it myself.

[plasticine]

Sure! If I get a moment I might try tackling it myself.

@Aaronius That would be amazing 💖