-
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
@@toStringTag
property not present on modules passed to hookFn
#57
Comments
This was referenced Jan 23, 2024
Closed
This was referenced Mar 18, 2024
trentm
added a commit
to trentm/import-in-the-middle
that referenced
this issue
Mar 28, 2024
The README example says the Hook callback `exported` arg is "effectively `import * as exported from ${url}`". https://tc39.es/ecma262/#sec-module-namespace-objects specs that a Module Namespace Object has a @@toStringTag property with value "Module" and no constructor. Fixes: nodejs#57
bengl
pushed a commit
that referenced
this issue
Apr 17, 2024
The README example says the Hook callback `exported` arg is "effectively `import * as exported from ${url}`". https://tc39.es/ecma262/#sec-module-namespace-objects specs that a Module Namespace Object has a `@@toStringTag` property with value "Module" and no constructor. Fixes: #57 Obsoletes: #64 * * * This behaviour changed with the changes in #43 when the `register(...)`'d namespace changed from using an actual imported module object to using a plain object with module properties copied over to it: https://github.com/DataDog/import-in-the-middle/pull/43/files#diff-e69a24a4c3746fa1ee96a78e12bb12d2dd4eb6e4cacbced2bf1f4084952681d9L130-R208 I suspect that was an unintentional change. The main question here is **whether you would like import-in-the-middle to promise this**: that the `exported` namespace returned to the `Hook` callback mimics this aspect of `import * as exported from '...'`. As links to #57 show, this would help the OpenTelemetry JS project. I [started](open-telemetry/opentelemetry-js-contrib#1694 (comment)) using `exported[Symbol.toStringTag]` in OpenTelemetry instrumentations a while back as a way to handle differences in instrumentating a module based on whether it was being used from ESM code vs CommonJS code. This is convenient because **OpenTelemetry core instrumentation code uses the same hook function for require-in-the-middle and import-in-the-middle hooks**. It also seemed reasonable given the `Module Namespace Object` spec entry. However, I grant that the `exported` arg need not be a Module Namespace Object. * * * Assume you are willing to accept this, a note on my implementation: I chose to explicitly add the `@@toStringTag` property because: - it is more explicit - the `for (const k of Object.getOwnPropertySymbols(primary)) { ... }` alternative (proposed in #57 and #64) will only ever include the `@@toStringTag`. Assuming my read of the https://tc39.es/ecma262/#sec-module-namespace-objects and https://tc39.es/ecma262/#sec-module-namespace-exotic-objects sections is correct, the module object will only ever have *string* keys (for the "export"s), plus the one `@@toStringTag` property. - the `@@toStringTag` property should not be enumerable (i.e. `Object.getOwnPropertyDescriptor(exported, Symbol.toStringTag).enumerable === false`). The other implementation does not persist that descriptor value.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Expected Behavior
Using
Hook
, the module passed tohookFn
includes@@toStringTag
property as was the case up untilimport-in-the-middle@1.7.1
Actual Behavior
Using
Hook
, the module passed tohookFn
does not include the@@toStringTag
property.Steps to Reproduce the Problem
npm init
npm install --save-exact koa@2.15.0
(used as an example)npm install --save-exact import-in-the-middle@1.7.3
index.mjs
node --loader=import-in-the-middle/hook.mjs index.mjs
This failsHowever, doing the same with
import-in-the-middle@1.7.1
works as expected:npm install --save-exact import-in-the-middle@1.7.1
node --loader=import-in-the-middle/hook.mjs index.mjs
This succeedsAdditional info
I'm not certain that this is safe, but adding this to the generated code in
hook.js
after L312 includes the property from the primary namespace and seems to fix the issue.Specifications
The text was updated successfully, but these errors were encountered: