Types that are found, but not exported in package.json, should still be usable

[justinfagnani]

Suggestion

With module resolution "Node16" or "NodeNext" I'm running into problems using packages where tsc can find declaration files but won't use them because they're not exported in package.json.

The error I get is:

error TS7016: Could not find a declaration file for module '@web/dev-server'. '/Users/justin/Projects/Web/simple-story-viewer/node_modules/@web/dev-server/index.mjs' implicitly has an 'any' type.
  There are types at '/Users/justin/Projects/Web/simple-story-viewer/node_modules/@web/dev-server/dist/index.d.ts', but this result could not be resolved when respecting package.json "exports". The '@web/dev-server' library may need to update its package.json or typings.

This means that I can't use the package without copying it's types or patching the package locally with something like patch-package.

I know the package should technically be exporting its types correctly (though I might argue that this is being overly pedantic and that the existence of the these specific files strongly implies that the author intended them to be used), but as a user of TypeScript I'm stuck and tsc seems to have enough information to just laod the types for me so I can at least make progress.

I'd like some sort of option to tell tsc to loosen up about these files. If there's an encapsulation violation or something breaks with the next version of the package I'm using, I'll deal with it.

It's also possible that behavior is a bug. As commented on by @andrewbranch in #46334:

a foolproof way to write a valid project structure and package.json file is just to publish your declaration files in the same place as their partner JS files and literally never write types anywhere in your package.json.

This seems to say that if I'm importing index.mjs and there's an index.d.ts next to it, the types should load. Is that correct?

🔍 Search Terms

• package export types
• this result could not be resolved when respecting package.json "exports"

A lot of issues came up in the first search. I could have missed a duplicate.

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

An option to load types not exported in packae.json.

📃 Motivating Example

https://github.com/modernweb-dev/web/blob/master/packages/dev-server/package.json

💻 Use Cases

Packages that aren't ready for TypeScript's strict type loading behavior.

[Andarist]

This seems to say that if I'm importing index.mjs and there's an index.d.ts next to it, the types should load. Is that correct?

Yes, but index.d.ts is not a "sibling" file to index.mjs - that would be index.d.mts.

You can often debug such issues with tsc --traceResolution. If I run this in your repo (after setting up a fixture~ dir) then I can find there this:

...
Matched 'exports' condition 'import'.
Using 'exports' subpath '.' with target './index.mjs'.
File name '/modernweb-dev-web/node_modules/@web/dev-server/index.mjs' has a '.mjs' extension - stripping it.
File '/modernweb-dev-web/node_modules/@web/dev-server/index.mts' does not exist.
File '/modernweb-dev-web/node_modules/@web/dev-server/index.d.mts' does not exist.
...

[justinfagnani]

So is the error wrong then?

The error is saying that the file just needs to be in exports, but really the issue is that the file has the wrong extension.

[andrewbranch]

The error is not wrong; it does not say that the file needs to be listed in exports. It says it was unresolvable while respecting exports. If we had never looked at exports, we would have looked at main instead, which has a corresponding typings file.

index.d.ts cannot be used to type index.mjs. The former is obviously a CJS module while the latter is obviously an ES module. The error isn’t saying “hey we found the file you probably meant, but in the interest of being overly pedantic, we’re not going to load it.” It’s saying that we found a typings file, so the author clearly intended to include types, but we have no idea what to load for the ESM entrypoint.

This means that I can't use the package without copying it's types or patching the package locally with something like patch-package.

The hope was that folks would open issues, not just work around it for themselves 😕

[andrewbranch]

Something that would be nice to have is a way for library authors to indicate that a CJS .d.ts file can undergo some kind of trivial static transformation (in memory, built into tsc) and become an accurate (synthesized) ESM declaration file. That would make it easier for library authors to fix these issues, and then perhaps there could be a flag like you suggest, which would apply that transformation based on filename heuristics.

(In this case, it looks like no syntactic transformation is actually required, but I think in general you need to know whether to set the CJS module exports to the default export of the ES module. For example, if the CJS file module.exports a class or function, its ESM counterpart likely does an export default. On the other hand, if a CJS file module.exports an object literal, the ESM counterpart might export default that object literal, or it might do a named export for each of the object literal keys, or it might do both. It just depends on how the original module was authored and what tool was used to do the dual emit. Consequently, I don’t know that we could automatically pick a correct transform at all—I just wanted to explain why a transform is necessary in general, despite the fact that it would be a no-op on the example you provided. Even in the case that the content of a .d.ts file would be identical if it were changed to be a .d.mts file, we need the infrastructure to be able to treat the .d.ts file as a CJS module when it’s resolved normally but as an ES module when it’s resolved as the stand-in for a missing .d.mts file.)

I’ll continue thinking about this, but I think the version of this option that you’re asking for is too loose. At the same time, so many libraries are misconfigured that everyone would turn it on, and we would forever lose the ability to do something more correct. In the meantime, please do let the library maintainers for @web/dev-server know that they are missing an index.d.mts file.

[typescript-bot]

This issue has been marked as 'External' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[dhruvkelawala]

This seems like a very prominent issues with many packages that I am trying to use in my project with Typescript v5.0-beta and moduleResolution: bundler.
A really common package that many might be using with Vite, also has this issue.

https://github.com/gxmari007/vite-plugin-eslint

[Andarist]

Here you go, I fixed this for you: gxmari007/vite-plugin-eslint#60

[dhruvkelawala]

That was fast. Thank you!