There seems to be some incompatibility with the package Proxyquire.
You can't import it, for reasons I don't quite understand.
import proxyquire from 'proxyquire';
import * as proxyquire from 'proxyquire';
import proxyquire;
All these will give the same error:
TypeError: Cannot read property 'exports' of undefined
I managed to import it by using a normal CJS module to require and immediately export it.
If you're unaware, what proxyquire does, is that it will require a module, while proxying whatever the required module would in turn require.
This is broken by esm.
You would specify the path to the proxied module, but it will complain that it can't be found.
I highly suspect this is due to something esm is doing.
It would be nice if someone could shed some light at what is going on, and if possible suggest a solution or alternative.
Thanks @Jovaage!
Patched https://github.com/standard-things/esm/commit/d9788b3f45b2f680f435250b24133cd137977239.
This did indeed fix importing of the module.
However there still incompatibilities.
The module imported by proxyquire, it seems, will not be run through esm first.
This code:
// a.mjs
import fs from 'fs';
// test.mjs
import proxyquire from 'proxyquire';
proxyquire('./a.mjs', {});
md5-b42f53d04e022413cdd21a72f6125dab
.../a.mjs:2
import fs from 'fs';
^^^^^^
SyntaxError: Unexpected token import
at Object.exports.runInThisContext (vm.js:78:16)
at Module._compile (module.js:543:28)
at Object.Module._extensions..js (module.js:580:10)
at Object.require.extensions.(anonymous function) [as .js] (.../node_modules/proxyquire/lib/proxyquire.js:276:43)
at Module.load (module.js:488:32)
at tryModuleLoad (module.js:447:12)
at Function.Module._load (module.js:439:3)
at _.Module.require (module.js:498:17)
at Proxyquire._withoutCache (.../node_modules/proxyquire/lib/proxyquire.js:179:12)
at Proxyquire.load (.../node_modules/proxyquire/lib/proxyquire.js:136:15)
I realize this might not be esm's fault.
If it isn't, and you believe it's fixable by proxyquire, I will add an issue there instead.
I am running into the same issue.
@Jovaage
Since proxyquire proxies require and require doesn't support ESM this makes sense.
You might try unlocking CJS compat with "cjs": true.
I have the following settings:
"@std/esm": {
"cjs": true,
"esm": "js"
}
and I have not converted my test to using imports, so it still requires proxyquire:
const proxyquire = require('proxyquire').noCallThru()
With this, I get the same SyntaxError: Unexpected token import error from the file I am proxyquiring. If I switch to importing proxyquire instead of requiring it, I get an error about the import in the test file instead of the one I am proxyquiring.
I am running mocha --require @std/esm ./src/test but also use mocha programatically.
Adding "cjs": true sadly makes no difference
Adding
"cjs": truesadly makes no difference
Cool. That's likely because of our opt-in guards so we don't step on others toes.
(proxyquire isn't opt-ing in so it doesn't get the enhanced require)
This will be tackled by #77 on our end. It will allow you to opt-in for all using an options object. This could also be tackled by proxquire if it accepted passing in the require function to wrap.
With #77 part of 0.8.0+, is there an example of getting proxyquire to work or can it only be done by passing require in?
@eliw00d bootstrap your test file with custom options:
require = require("@std/esm")(module, { cjs: true, esm: "js" })
or true to force the ones specified in your package.json
require = require("@std/esm")(module, true)
then load your test file that includes proxyquire:
```js
require("./test.mjs")
So, I have been running all my test files via mocha -r @std/esm ./src/test --recursive until I can get it to work programmatically, and most of them require proxyquire. By doing it that way, wouldn't it already be using the options in my package.json?
Just a note that I'm hitting issues with proxyquire for testing with @std/esm 0.18.0
@gauntface
How are you using proxyquire and std/esm?
Are you using std/esm via the -r flag?
Related to proxyquire/issues/173. They're open to a PR if you're willing to dig in.
Running as nyc --require @std/esm mocha
Thanks for the linked bug - I'm happy just assuming it won't be supported and either alter tests or alter when we use @std/esm (fortunately proxyquire is only used for node packages where we can get away with not using requiring @std/esm).
Ah ok. Cool! Let me know if anything becomes a blocker and I'll work to unblock it 馃構
Most helpful comment
This did indeed fix importing of the module.
However there still incompatibilities.
The module imported by
proxyquire, it seems, will not be run throughesmfirst.This code:
I realize this might not be
esm's fault.If it isn't, and you believe it's fixable by
proxyquire, I will add an issue there instead.