Closed trentm closed 1 month ago
I forgot to /cc @jsumners-nr and @bengl when I opened this. Please see above. Thanks.
I'd need to review the comments I left throughout. But the fact is, we are basically re-implementing the parsing and tree building of ESM, and there are way too many permutations to consider in that spec.
If my code is wrong and you know how to make it right: please make it so.
The
renamedExport
handling from https://github.com/DataDog/import-in-the-middle/pull/53 incorrectly adds ES module exports. Given these three small test files:When run without IITM, we expect the import of './default-and-star-b.mjs' to only have the
valueA
andvalueB
exports:However, when running with IITM (at tip of current "main") a
renamedExport
for theexport * from './default-and-star-a.mjs';
statement in "default-and-star-b.mjs" is incorrectly added:Was this possibly a misunderstanding of import behaviour while working on #53? The #53 description says:
Where did the impression that "default exports get mapped to some other name for the module that has imported them" come from? Or perhaps I'm not following what the is saying.
Also the change to "hook.js" includes this comment:
Is this possibly a misunderstanding as well? Taking the "default-and-star-b.mjs" example from above:
That
export * ...
statement does not re-export thedefault
export from "default-and-star-a.mjs". Therefore, there should not be any need for import-in-the-middle to be adding some normalization of that property name to the hooked namespace or have a setter for it.Assuming we agree this is a bug that should be fixed (i.e. that this was a misunderstanding), I'll have a draft PR soonish to fix this, along with some simplifications in
getSource
andprocessModule
.