Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidance around exports.types config when authoring in TS #990

Closed
jeffposnick opened this issue Aug 20, 2022 · 3 comments · Fixed by #992
Closed

Guidance around exports.types config when authoring in TS #990

jeffposnick opened this issue Aug 20, 2022 · 3 comments · Fixed by #992

Comments

@jeffposnick
Copy link
Contributor

I'm authoring a module in TypeScript that I'm bundling and publishing with microbundle. I would like the published module to be importable from a wide range of projects, with the generated TypeScript definitions to be available as well.

The "Using with TypeScript" guide does not mention one piece of configuration that I've found necessary. In order to produce a module that can be imported from TypeScript projects with moduleResolution: "NodeNext" configured, with the .d.ts definitions available as well, I needed to add an exports.types field to my module's package.json config.

Without adding in that types field, I get the standard ts(7016) error when using my module from moduleResolution: "NodeNext" projects, informing me that there are no type definitions.

I'm happy to file a PR against the microbundle docs instructing developers to set exports.types for maximum compatibility with modern TypeScript.

@rschristian
Copy link
Collaborator

Would love docs there if you're willing.

Adding that to the main package.json example would also be appreciated, assuming I'm understanding correctly and that exports.types is necessary despite no subpath exports (hope I'm wrong because boy do I hate that).

@melanieseltzer
Copy link

melanieseltzer commented Oct 9, 2022

Sorry to dig up a closed issue, but just wanted to clarify - does the exports.types field only need to be specified if you need to override where TypeScript typically looks for corresponding declaration files?

It kind of reads that way to me in the docs, so I'm a tad confused:

By default, TypeScript overlays the same rules with import conditions - if you write an import from an ES module, it will look up the import field, and from a CommonJS module, it will look at the require field. If it finds them, it will look for a colocated declaration file. If you need to point to a different location for your type declarations, you can add a "types" import condition.

The above reads to me as though it will automatically find the declaration file as long as it's colocated with the file specified under import/require, if not, then you need to point exports.type to where it is?

@rschristian
Copy link
Collaborator

does the exports.types field only need to be specified if you need to override where TypeScript typically looks for corresponding declaration files?

Theoretically. I've had some issues with that in the past so I don't really trust their lookup mechanisms. It's a tad fragile too.

The above reads to me as though it will automatically find the declaration file as long as it's colocated with the file specified under import/require, if not, then you need to point exports.type to where it is?

It needs to be colocated and match the file name, i.e, if the imported file is foo.js, then your declaration needs to be foo.d.ts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants