Typings issue with v3

[EdJoPaTo]

Even with bugfix release v3.0.1 there seem to be an issue with typings from external packages.
For example Ava does not seem to work after upgrading to v3. But this issue is not exclusive to ava so I suspect either some problem with this tsconfig or some issue more packages did.

I created a minimal example of this issue and the PR updates to v3.0.1. The check on the main branch (v2) works fine while v3 fails.

https://github.com/EdJoPaTo/sindresorhus-tsconfig-ava-issue-minimal-example/pull/1

I don't know what the exact issue might be but I wanted to create a minimal example that can be looked upon more easily.

I suspected esModuleInterop but it isn't the case, it does not change the behaviour.
I suspected some CommonJS / ES modules mixup but the minimal example is strictly only ES modules so it shouldn't be the case either?

tsc Error message (the second results from the first):

test/test.ts:1:18 - error TS7016: Could not find a declaration file for module 'ava'. '…/sindresorhus-tsconfig-ava-issue-minimal-example/node_modules/ava/entrypoints/main.mjs' implicitly has an 'any' type.
  Try `npm i --save-dev @types/ava` if it exists or add a new declaration (.d.ts) file containing `declare module 'ava';`

1 import test from 'ava';
                   ~~~~~

test/test.ts:5:24 - error TS7006: Parameter 't' implicitly has an 'any' type.

5 test('whatever works', t => {
                         ~

[sindresorhus]

avajs/ava#3024

[EdJoPaTo]

The common reason why imports failed for me seem to be the required fully specified path in the main/types package.json key of the package to be imported:

-"main": "dist",
-"types": "dist",
+"main": "./dist/index.js",
+"types": "./dist/index.d.ts",

Changing that in the to be imported package allows the use of it with this config.

Alternatively the exports keyword achieves something similar like described in the announcement of TS 4.7.

I know that only ES Modules are supported since v1.0.0 and neither the TypeScript 4.7 nor Node.js 14 mentioned in the v3 release were the reason for this breakage. As far as I understand currently the moduleResolution changed with v3 was the reason. While dependencies are already "type": "module", they didnt seem to work. They also required fully specified exports (via main/types or exports). That wasn't obvious to me from the v3 update release notes. As ES Modules are already required and they basically require fully specified paths this isn't related to the v3 release directly either but it only showed up here and not earlier. Not sure if this should be stated in the release notes of v3 as ESM is already required since v1.0.0.
I hope stating this in this issue can help other package maintainers with a similar issue to solve it for them too.

Feel free to close it as it seems solved for me or keep it open for better visibility for others.

[fregante]

I can confirm that with moduleResolution: node16 hell breaks loose for me. TS expects types sub dependencies to have extensions in imports as well, making this change as annoying as worse than upgrading to ESM itself because it requires ALL dependencies to be compatible.

node_modules/webext-content-scripts/index.d.ts:2: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.

2 import type { ContentScript } from './types';
                                     ~~~~~~~~~

source/test/background/api.test.ts:11:8 - error TS2835: Relative import paths need explicit file extensions in EcmaScript imports when '--moduleResolution' is 'node16' or 'nodenext'. Did you mean './api.js'?

11 } from "./api";
          ~~~~~~~

The second is fixable locally, the first one requires a new version of the dependency