-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getExports
used for node v20, v18.19.0 doesn't handle reexports
#29
Comments
In case it's useful, as I've been debugging related issues for my own setup, I took a rough pass at a patch to expose the reexports. This is not my area of expertise so I make no claims that this is the correct way of doing it, but it at least appears to work in my use case. The following is what I applied (via patch-package - diff --git a/node_modules/import-in-the-middle/lib/get-exports.js b/node_modules/import-in-the-middle/lib/get-exports.js
index cfa86d4..d93516a 100644
--- a/node_modules/import-in-the-middle/lib/get-exports.js
+++ b/node_modules/import-in-the-middle/lib/get-exports.js
@@ -3,12 +3,26 @@
const getEsmExports = require('./get-esm-exports.js')
const { parse: getCjsExports } = require('cjs-module-lexer')
const fs = require('fs')
-const { fileURLToPath } = require('url')
+const { fileURLToPath, pathToFileURL } = require('url')
function addDefault(arr) {
return Array.from(new Set(['default', ...arr]))
}
+async function getFullCjsExports(url, context, parentLoad, source) {
+ const ex = getCjsExports(source)
+ return Array.from(new Set([
+ ...addDefault(ex.exports),
+ ...(await Promise.all(ex.reexports.map(re => getExports(
+ re.startsWith('./') || re.startsWith('../')
+ ? pathToFileURL(require.resolve(fileURLToPath(new URL(re, url)))).toString()
+ : pathToFileURL(require.resolve(re)).toString(),
+ context,
+ parentLoad
+ )))).flat()
+ ]))
+}
+
async function getExports (url, context, parentLoad) {
// `parentLoad` gives us the possibility of getting the source
// from an upstream loader. This doesn't always work though,
@@ -33,7 +47,7 @@ async function getExports (url, context, parentLoad) {
return getEsmExports(source)
}
if (format === 'commonjs') {
- return addDefault(getCjsExports(source).exports)
+ return getFullCjsExports(url, context, parentLoad, source)
}
// At this point our `format` is either undefined or not known by us. Fall
@@ -44,7 +58,7 @@ async function getExports (url, context, parentLoad) {
// isn't set at first and yet we have an ESM module with no exports.
// I couldn't construct an example that would do this, so maybe it's
// impossible?
- return addDefault(getCjsExports(source).exports)
+ return getFullCjsExports(url, context, parentLoad, source)
}
} |
@luxaritas Yes, this seems like a great start. Can you move it to a draft PR, and add tests? |
Done - let me know if there's anything else I can do to help! |
getExports
used for node v20 doesn't handle reexportsgetExports
used for node v20, v18.19.0 doesn't handle reexports
this issue is still happening, is there any fix for it or workaround? |
Resolves #29 --------- Co-authored-by: Trent Mick <trentm@gmail.com> Co-authored-by: rochdev <roch.devost@gmail.com>
import-in-the-middle hooking of a CommonJS module that has reexports breaks usage of that module. For example:
Steps to Reproduce the Problem
details
Adding this console.log to import-in-the-middle/lib/get-exports.js:
and re-running:
That shows the "reexports" I'm referring to.
I was kind of surprised that
cjs-module-lexer
recognizedtslib_1.__exportStar(require("./S3Client"), exports);
and similar as a "reexport". Does it have particular smarts abouttslib
or is it parsing and/or executing tslib?Does import-in-the-middle want/need to get into recursively handling these "reexports"?
The text was updated successfully, but these errors were encountered: