proxyquire "magic" invalidates strict-mode

[smcatala]

• proxyquire-plugin injects an IIFE at the start of scripts that require("proxyquire").
• the injected IIFE is inserted before any "use strict" statement in the script, invalidating strict-mode.
• to work around this behaviour, the script can for example be encapsulated in a strict-mode function, e.g. an IIFE or a describe block.

please check this repository for a demonstration of this issue, based on the differing interpretation of "this" in an unbound function.

[bendrucker]

Do you have a proposed solution?

[smcatala]

not sure:

• least intrusive: document this behaviour and the work-around,
• or add an option to disable the proxyquire magic (injection) and let users add the require statement for browserify,
• or encapsulate the script into an IIFE before injecting the proxyquire magic. the IIFE would need to pass along the arguments from browserify. nervous about adding more modifications to the original script: this could be an option of the plugin,
• or insert the magic in an IIFE where proxyquire-universal replaces the require("proxyquire") with require("proxyquireify")("require"):

  (function () {
  function __makeBrowserifyIncludeModule__() {
  require('../src/index.ts')
  }
  return require("proxyquireify")("require")
  }())

  in any case, an option to disable the injection would be a good safeguard.

[bendrucker]

Not interested in offering an option to disable the automatic requires. Those are there to include packages in the bundle. Omitting them removes important behavior that's difficult for users to replicate.

Your last example sounds ok.

To clarify, is it the requires that proxyquireify injects or the rewriting that proxyquire-universal does? They're two different projects.

[smcatala]

the last suggestion refers to the rewriting that proxyquire-universal does. not sure if proxyquireify with the proxyquire-plugin could do this.

[bendrucker]

Would appreciate a PR then. You keep referring to proxyquireify-plugin and I don't know what this is. Happy to keep this open for a bit if you're interested in solving it.

[smcatala]

proxyquire-plugin is described in the API of this project.

here is the code from the proxyquire-plugin that injects the 'magic'. the idea might be to use code from your proxyquire-universal project, more specifically the transform code, to inject the magic.

note that the features listed in the documentation include "use strict" compliant. until a PR is ready, it might be worthwhile mentioning this limitation.

[bendrucker]

Oh, when you used the hyphen I assumed you were referring to a module and not the proxyquire.plugin function. You can just call it proxyquireify for clarity.

proxyquireify does not know about the existence of proxyquire-universal so a solution might need to be applied to both projects independently.

[smcatala]

sorry for the confusing denomination.

[bendrucker]

All good, if we ever want to do another major release the whole object w/ a plugin method can go in favor of a plain function export.

[bendrucker]

In any case, if you want to take a stab at a PR I'd be happy to guide. The first step can be to open w/ a failing test in the appropriate project. proxyquire-universal is so simple and only touches a single line. I looked around a bit and can't see how it would be involved here.

Pretty certain this all comes down to this change from a while ago and you're just the first to notice the regression: https://github.com/thlorenz/proxyquireify/commit/0d5fe82f00b2a9e12c138f59544569cae1fb220d

It might be enough to switch the order of the require-shim and source code (https://github.com/thlorenz/proxyquireify/blob/0d5fe82f00b2a9e12c138f59544569cae1fb220d/lib/transform.js#L25-L26).