Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext #50223

benasher44 · 2022-08-08T16:34:30Z

Bug Report

Setting noImplicityAny to true triggers transitive import errors like this, when using "moduleResolution": "nodenext":

node_modules/@tiptap/core/dist/packages/core/src/helpers/isTextSelection.d.ts:1:31 - error TS7016: Could not find a declaration file for module 'prosemirror-state'. '/Users/basher/code/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' implicitly has an 'any' type.
  Try `npm i --save-dev @types/prosemirror-state` if it exists or add a new declaration (.d.ts) file containing `declare module 'prosemirror-state';`

1 import { TextSelection } from 'prosemirror-state';
                                ~~~~~~~~~~~~~~~~~~~

In this setup, we're importing @tiptap/core, which is importing prosemirror-* packages. @tiptap/core is a CommonJS package. prosemirror-* packages have exports maps and appear to support CommonJS and ESM correctly. I should also note that prosesmirror-* packages come with their own types (i.e. no @types/* packages needed)

Setting noImplicitAny to true triggers these errors. Setting it to false makes them disappear (successful compile).

🔎 Search Terms

nodenext
esm
import

🕗 Version & Regression Information

With the TS 4.7 release, we're trying to migrate to NodeNext as a step to getting to ESM. It wasn't possible to use NodeNext on prior versions.

⏯ Playground Link

I can't figure out how to add node_modules to TS Playground, but I'd be happy to provide a playground link, if someone can advise there.

https://github.com/benasher44/prosemirror-nodenext

💻 Code

tsconfig.json

{
  "compilerOptions": {
    "target": "ES6",
    "module": "ESNext",
    "esModuleInterop": true,
    "lib": [
      "DOM",
      "DOM.Iterable",
      "ES2021"
    ],
    "moduleResolution": "NodeNext",
    "outDir": "build",
    "allowSyntheticDefaultImports": true,
    "strict": true,
    "sourceMap": true,
    "declaration": true,
    "noImplicitAny": true,
  },
  "include": ["src/**/*", "__tests__/**/*"]
}

Add latest @tiptap/core to package.json (2.0.0-beta.182 in this case)

TS file that imports and consumes a type from @tiptap/core

import { JSONContent } from "@tiptap/core"; 

export function test(e: JSONContent): void {
    console.log(e);
}

🙁 Actual behavior

Errors that show TS can't find type declaration.

🙂 Expected behavior

Successful compile.

The text was updated successfully, but these errors were encountered:

benasher44 · 2022-08-09T18:11:38Z

Once an investigation is done, I have some follow up questions:

Are there other flags we could enable that would workaround this without giving up noImplicitAny?
Would pushing @tiptap to generate an ESM build help?
If this requires a patch to TS, would it be possible to get it into a 4.8.x (last remaining blocker for us to adopt ESM for node)?

eMuonTau · 2022-08-22T12:29:05Z

Same error with jsonpath-plus library which is an esm module and has builtin types.

jsonpath-plus has types declaration at the root level. If you also set types field in exports section, it builds successfully. I think it should fallback to root types declaration.

jsonpath-plus was the only package that caused this error. In my case there is a single d.ts file and i temporarily fixed by copying jsonpath.d.ts file to the project.

Not working

"exports": {
    ".": {
      "import": "./dist/index-node-esm.js"
    }
  },
"types": "./src/jsonpath.d.ts",

Working

"exports": {
    ".": {
      "import": {
        "types": "./src/jsonpath.d.ts",
        "default": "./dist/index-node-esm.js"
      },
    }
  },
"types": "./src/jsonpath.d.ts",

benasher44 · 2022-09-21T20:36:59Z

With 4.9 beta coming along, I was wondering if TypeScript folks had a chance to look at this one yet? Thanks!

sheetalkamat · 2022-10-05T17:47:03Z

Here is the example of error:

node_modules/@tiptap/core/dist/packages/core/src/CommandManager.d.ts:1:42 - error TS7016: Could not find a declaration file for module 'prosemirror-state'. 'C:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' implicitly has an 'any' type.
  Try `npm i --save-dev @types/prosemirror-state` if it exists or add a new declaration (.d.ts) file containing `declare module 'prosemirror-state';`

1 import { EditorState, Transaction } from 'prosemirror-state';

Package.json for @tiptap/core:

{
  "name": "@tiptap/core",
  "main": "dist/tiptap-core.cjs.js",
  "umd": "dist/tiptap-core.umd.js",
  "module": "dist/tiptap-core.esm.js",
  "types": "dist/packages/core/src/index.d.ts",

Here are the resolution steps:

======== Resolving module 'prosemirror-state' from 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/CommandManager.d.ts'. ========
Explicitly specified module resolution kind: 'NodeNext'.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/package.json' exists according to earlier cached lookups.
Loading module 'prosemirror-state' from 'node_modules' folder, target file type 'TypeScript'.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/node_modules' does not exist, skipping all lookups in it.
Found 'package.json' at 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/package.json'.
'package.json' does not have a 'typesVersions' field.
File name 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' has a '.cjs' extension - stripping it.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cts' does not exist.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.d.cts' does not exist.
File 'c:/temp/prosemirror-nodenext/node_modules/@types/prosemirror-state.d.ts' does not exist.
Directory 'c:/temp/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/node_modules' does not exist, skipping all lookups in it.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/package.json' does not exist according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/package.json' exists according to earlier cached lookups.
Loading module 'prosemirror-state' from 'node_modules' folder, target file type 'JavaScript'.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/src/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/packages/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/dist/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/core/node_modules' does not exist, skipping all lookups in it.
Directory 'c:/temp/prosemirror-nodenext/node_modules/@tiptap/node_modules' does not exist, skipping all lookups in it.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/package.json' exists according to earlier cached lookups.
File 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' exist - use it as a name resolution result.
Resolving real path for 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs', result 'C:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs'.
======== Module name 'prosemirror-state' was successfully resolved to 'c:/temp/prosemirror-nodenext/node_modules/prosemirror-state/dist/index.cjs' with Package ID 'prosemirror-state/dist/[email protected]'. ========

The details about the file:

node_modules/@tiptap/core/dist/packages/core/src/CommandManager.d.ts
  Imported via './CommandManager' from file 'node_modules/@tiptap/core/dist/packages/core/src/index.d.ts' with packageId '@tiptap/core/dist/packages/core/src/[email protected]'
  File is CommonJS module because 'node_modules/@tiptap/core/package.json' does not have field "type"

Here is the package.json from prosemirror-state

{
  "name": "prosemirror-state",
  "type": "module",
  "main": "dist/index.cjs",
  "module": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  },

Clearly the package.json has exports field and its missing types which is the cause of this issue. I think we could give better experience by reporting "types" condition is missing in exports. But thing to note is these errors can be coming from node_modules packages. What are mitigation steps for this from user perspective.
In this scenario - which I think is practical scenario is that many packages will have .js and .cjs files side by side and they meant to use single typings file. But becase index.cjs doesnt look up index.d.ts but we aren't able to find. Do we need some tweaking in the rule where we look for .d.ts as well. Do we take this step when reporting diagnostics?.Do we know packages out there which have different shape depending on esm vs cjs.
If we look at @tiptap/core package.json, clearly it is also meant to support .cjs and esm. How do you make d.ts work as esm and cjs both depending on the context because to me thats what it feels like is intended.

@andrewbranch @weswigham to weigh in since you have spent lot of time on module resolution modes.
cc: @DanielRosenwasser @RyanCavanaugh

andrewbranch · 2022-10-13T18:54:35Z

Edit: this was is not good advice. ESM and CJS entrypoints should _always_ have separate type declaration files. Any package.json `exports` structure with `types`/`import`/`require` and no nested conditions underneath them, like the diff I suggested here, is wrong.

How do you make d.ts work as esm and cjs both depending on the context because to me thats what it feels like is intended.

{
  "name": "prosemirror-state",
  "type": "module",
  "main": "dist/index.cjs",
  "module": "dist/index.js",
  "types": "dist/index.d.ts",
  "exports": {
+   "types": "./dist/index.d.ts",
    "import": "./dist/index.js",
    "require": "./dist/index.cjs"
  }

I think we could give better experience by reporting "types" condition is missing in exports.

Yeah, there’s probably something we could do here, especially if the subpath was ., the condition was require, and there’s a top-level types.

But thing to note is these errors can be coming from node_modules packages. What are mitigation steps for this from user perspective.

File a bug or PR against the library.
The user could add an entry to paths if the relative path to the desired typings file is known and deterministic.

Do we know packages out there which have different shape depending on esm vs cjs.

Packages that use export default sym in ESM and module.exports = sym in CJS really need two different declaration files to express this accurately. I’m not sure of a real package example off the top of my head; this has come primarily for ESM-only packages whose typings fail to reflect that it’s ESM; see #50690.

benasher44 · 2022-10-18T10:35:52Z

@andrewbranch do you know what it is about noImplictAny that triggers this? I'm having trouble convincing the library maintainer that this is on them to fix (adding types entry under exports in addition to top-level), and I think explaining the why there would be helpful. Otherwise, it's hard to argue this isn't a TS bug, since a project that doesn't set that flag works fine with nodenext

benasher44 · 2022-10-18T10:42:28Z

It would also be helpful to know if there's a way to reproduce this with prosemirror alone. Going through tiptap I think is also adding to the edge-case-y feel to this issue.

andrewbranch · 2022-10-18T16:10:59Z

Not being able to resolve dependency typings is only an error in noImplicitAny. It doesn’t work fine without noImplicitAny; the typings aren’t found and the import is silently any.

benasher44 · 2022-10-18T18:16:16Z

Ah. Thanks! Super helpful. I was able to get a more minimal sample. I have updated the sample project. One thing I still don't quite understand. With the smaller example, the build fails with noImplicitAny set to true (as expected) if I remove "type": "module" from the package.json, but if I put "type": "module" (essentially switching from CJS to ESM), it passes. I don't understand why it would fail for CJS but pass for ESM.

andrewbranch · 2022-10-18T18:33:37Z

if I remove "type": "module" from the package.json

Are you referring to the dependency package.json or your own?

andrewbranch · 2022-10-18T18:59:20Z

Assuming you’re talking about your own—when you import the dependency as ESM, the type lookup works due to TypeScript’s extension substitution. The export map is consulted, the import condition is matched, which points to the path ./dist/index.js, which causes us to look for ./dist/index.ts (not found) followed by ./dist/index.d.ts (found).

Contrast this to what happens in the CJS case: the export map is consulted, the require condition is matched, which points to the path ./dist/index.cjs, which causes us to look for ./dist/index.cts (not found) followed by ./dist/index.d.cts (also not found).

In other words, .d.ts only applies to its sibling .js file by default; it takes a .d.cts extension to match with a .cjs file.

sheetalkamat · 2022-10-18T19:03:27Z

You can also use --traceResolution (to see the steps taken during module resolution) and --explainFiles (to know more information about files like was it treated as CJS or ESM based on package.json, why was file in the program etc)

benasher44 · 2022-10-18T20:06:29Z

Ah! Super interesting. Thanks again! I'll leave it to you all as to whether to close this.

It would be great if TS could provide a tool to run a diagnostic and print out a what is wrong with a library's package.json in a simple table (list what is missing or misconfigured, consequences of said misconfiguration, and resolution steps). Then we can just point library maintainers at that. If someone can make such a tool that is standalone-ish (or just a flag on tsc), more tools could be built on top of it (github actions, a bot that can be pinged on repos to check their package.json and print the diagnostic to a comment, etc.). What you just described makes sense to me now logically @andrewbranch, but the level of detail required to understand how that all fits together appears to continue to be a lot for maintainers. With the number of possible combinations that library authors have to prepare for to be ESM-ready, a tool would be super helpful in expediting fixes. Case in point, getting to where we are right now in this issue took over 2 months.

Also, I don't mean to imply that the tool would be easy to make by saying things like "simple table" and "just point library maintainers at that", but I do think a tool that presented simple output would go a long way here.

Thanks again for all of you all's help!

benasher44 · 2022-10-25T12:23:03Z

If it's at all possible to include more fallback behaviors that would make this scenario work, I would be appreciative. It appears I was unsuccessful at convincing this maintainer that this isn't just a bug in TypeScript ProseMirror/prosemirror#1305 (comment)

Otherwise, we'll just patch the library locally using yarn's patch facilities

andrewbranch · 2023-05-12T17:09:46Z

@sheetalkamat I think this can be closed as external.

benasher44 mentioned this issue Aug 8, 2022

Support for nodenext/node16 module resolution in TypeScript ProseMirror/prosemirror#1305

Closed

RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Aug 8, 2022

RyanCavanaugh assigned sheetalkamat Aug 8, 2022

RyanCavanaugh added this to the TypeScript 4.9.0 milestone Aug 8, 2022

This was referenced Nov 7, 2022

fix(react): add types field to esm exports map anddoutoi/chakra-ui#1

Open

fix(react): add types field to esm exports map chakra-ui/chakra-ui#6945

Merged

RyanCavanaugh added the Rescheduled This issue was previously scheduled to an earlier milestone label Feb 1, 2023

RyanCavanaugh modified the milestones: TypeScript 4.9.0, TypeScript 5.1.0 Feb 1, 2023

alexzhang1030 mentioned this issue May 6, 2023

fix: add types field to esm exports map vuetifyjs/vuetify#17305

Closed

sheetalkamat added External Relates to another program, environment, or user action which we cannot control. and removed Needs Investigation This issue needs a team member to investigate its status. Rescheduled This issue was previously scheduled to an earlier milestone labels May 15, 2023

sheetalkamat closed this as completed May 15, 2023

mcdurdin mentioned this issue Jun 7, 2023

chore(common): add restructure .d.ts for esm keymanapp/keyman#8945

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext #50223

Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext #50223

benasher44 commented Aug 8, 2022 •

edited

Loading

benasher44 commented Aug 9, 2022 •

edited

Loading

eMuonTau commented Aug 22, 2022 •

edited

Loading

benasher44 commented Sep 21, 2022

sheetalkamat commented Oct 5, 2022 •

edited

Loading

andrewbranch commented Oct 13, 2022 •

edited

Loading

benasher44 commented Oct 18, 2022

benasher44 commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

benasher44 commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

sheetalkamat commented Oct 18, 2022

benasher44 commented Oct 18, 2022 •

edited

Loading

benasher44 commented Oct 25, 2022

andrewbranch commented May 12, 2023

Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext #50223

Setting noImplicityAny to true triggers transitive import type declaration errors with moduleResolution NodeNext #50223

Comments

benasher44 commented Aug 8, 2022 • edited Loading

Bug Report

🔎 Search Terms

🕗 Version & Regression Information

⏯ Playground Link

💻 Code

🙁 Actual behavior

🙂 Expected behavior

benasher44 commented Aug 9, 2022 • edited Loading

eMuonTau commented Aug 22, 2022 • edited Loading

benasher44 commented Sep 21, 2022

sheetalkamat commented Oct 5, 2022 • edited Loading

andrewbranch commented Oct 13, 2022 • edited Loading

benasher44 commented Oct 18, 2022

benasher44 commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

benasher44 commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

andrewbranch commented Oct 18, 2022

sheetalkamat commented Oct 18, 2022

benasher44 commented Oct 18, 2022 • edited Loading

benasher44 commented Oct 25, 2022

andrewbranch commented May 12, 2023

benasher44 commented Aug 8, 2022 •

edited

Loading

benasher44 commented Aug 9, 2022 •

edited

Loading

eMuonTau commented Aug 22, 2022 •

edited

Loading

sheetalkamat commented Oct 5, 2022 •

edited

Loading

andrewbranch commented Oct 13, 2022 •

edited

Loading

benasher44 commented Oct 18, 2022 •

edited

Loading