Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stumbled upon some unexpected behavior when having AsyncIterator as a (sub)depenency of a TypeScript project with configured to use the
Node16
,NodeNext
orBundler
module resolution mechanisms. This probably did not turn up earlier because most packages in the ecosystem still compile to CommonJS modules, for which TypeScript defaults to the oldNode
module resolution mechanism.The issue
When checked with AreTheTypesWrong, we get the following report.
The problem is explained in the linked page: "In newer TypeScript resolution modes, however, TypeScript understands that an import in Node will resolve to index.mjs, and so it looks for a declaration file named index.d.mts, which doesn’t exist." (For more info, also see the TypeScript Handbook.)
The solution
My first attempt at solving this (993c734) was to simply mention the same type declarations twice in the
exports
object of the manifest. While this solved my concrete compilation errors, it still left the following "warning" when running AreTheTypesWrong.Again, this new issue is explained in the linked page: "Import resolved to an ESM type declaration file, but a CommonJS JavaScript file."
That page also lists more consequences than the error I encountered: "TypeScript will not allow consumers in CommonJS files to import/require the module without using await import("pkg"), even though that won’t actually be needed at runtime. In Node, an ES module cannot be accessed with require, so TypeScript will report this as an error at compile time. Note that in CommonJS TypeScript files (.cts, .ts with no package.json "type": "module"), top-level import declarations are emitted as require variable declarations (since CommonJS files cannot use import/export in Node), so this problem can occur even when the consumer is using import syntax."
So, as a second attempt (a5a7bc6) I actually compiled the type declarations files for both module types separately. This gives the desired result. Tests also still run fine, and on @rubensworks' request I tested actual imports in CommonJS and ECMAScript modules from Node.js v12.22.12 onward.