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:

https://github.com/plasticine/inject-loader/blob/14d573a1b17bcd7b5d37c8163f2fe08b4f04625c/index.js#L55

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 https://github.com/plasticine/inject-loader/issues/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 💖