Typechecking fails with "moduleResolution": "node16" or "nodenext"

[jameshfisher]

Initial checklist

• I read the support docs
• I read the contributing guide
• I agree to follow the code of conduct
• I searched issues and couldn’t find anything (or linked relevant results below)

Affected packages and versions

[email protected]

Link to runnable example

https://github.com/jameshfisher/bug-report-remark-node16

Steps to reproduce

Set "moduleResolution" to "node16" or "nodenext" in tsconfig.json.

Run tsc.

Expected behavior

No typechecking errors.

Actual behavior

$ npm run build

> [email protected] build
> tsc

example.ts:10:10 - error TS2367: This comparison appears to be unintentional because the types '"link" | "html" | "strong" | "image" | "text" | "linkReference" | "emphasis" | "delete" | "break" | "footnote" | "inlineCode" | "imageReference" | "footnoteReference"' and '"textDirective"' have no overlap.

10   return p.type === "textDirective";
            ~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/mdast-util-directive/index.d.ts:14:69 - error TS2694: Namespace '"/Users/jim/dev/tmp/test-remark-node16/node_modules/mdast-util-to-markdown/lib/types"' has no exported member 'Context'.

14 export type Context = import('mdast-util-to-markdown/lib/types.js').Context
                                                                       ~~~~~~~

node_modules/mdast-util-directive/index.d.ts:17:41 - error TS2834: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Consider adding an extension to the import path.

17 export type ContainerDirective = import('./complex-types').ContainerDirective
                                           ~~~~~~~~~~~~~~~~~

node_modules/mdast-util-directive/index.d.ts:18:36 - error TS2834: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Consider adding an extension to the import path.

18 export type LeafDirective = import('./complex-types').LeafDirective
                                      ~~~~~~~~~~~~~~~~~

node_modules/mdast-util-directive/index.d.ts:19:36 - error TS2834: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Consider adding an extension to the import path.

19 export type TextDirective = import('./complex-types').TextDirective
                                      ~~~~~~~~~~~~~~~~~


Found 5 errors in 2 files.

Errors  Files
     1  example.ts:10
     4  node_modules/mdast-util-directive/index.d.ts:14

Affected runtime and version

Node 16

Affected package manager and version

npm 8

Affected OS and version

macOS

Build and bundle tools

No response

[jameshfisher]

The root cause seems to be these lines, which omit the .js extension from the import:

mdast-util-directive/index.js

Lines 12 to 14 in ffcc82c

	* @typedef {import('./complex-types').ContainerDirective} ContainerDirective
	* @typedef {import('./complex-types').LeafDirective} LeafDirective
	* @typedef {import('./complex-types').TextDirective} TextDirective

This is an error according to TypeScript policy: microsoft/TypeScript#52412

I suggest these lines should have .js added to them?

[ChristianMurphy]

Thanks @jameshfisher!
node16 module resolution support is an ongoing effort across the unified/syntax-tree/remark ecosystems.
Pull requests are welcome!

I appreciate your time opening this.
As this will be going out to 300+ repos, and we don't necessarily want 300+ tracking issues for this. 😅
I'm going to close this issue, but know that:

• node16 resolution is planned and in progress
• pull requests helping the effort move forward are welcome and appreciated
• feel free to follow up with questions or further discussion here or in the syntax-tree discussion board https://github.com/orgs/syntax-tree/discussions

Thanks again! 🙇

[github-actions]

Hi! Thanks for taking the time to contribute!

Because we treat issues as our backlog, we close duplicates to focus our work and not have to touch the same chunk of code for the same reason multiple times. This is also why we may mark something as duplicate that isn’t an exact duplicate but is closely related.

Thanks,
— bb

[github-actions]

Hi team! It seems this post is a duplicate, but hasn’t been marked as such. Please post a comment w/ Duplicate of #123(no final .) to do so. See GH docs for more info.

Thanks,
— bb