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

Support for TypeScript moduleResolution: "node16" #283

Closed
toerndev opened this issue Jan 31, 2023 · 3 comments
Closed

Support for TypeScript moduleResolution: "node16" #283

toerndev opened this issue Jan 31, 2023 · 3 comments

Comments

@toerndev
Copy link

toerndev commented Jan 31, 2023

TypeScript currently cannot detect wouter's types if moduleResolution is set to "node16" or "nodenext".

This seems to be fixed by referencing the type files for each element under exports:

".": {
  "types": "./types/ts4.1/index.d.ts",
  "require": "some path",
  "default": "some path"
},
"/use-location": "same idea as above"

and so on. types has been added. Is this something that could be added safely?
If not, I think the same result is achieved by ensuring that the .d.ts files are located next to their JS counterparts (but they aren't in wouter).

Here's a long discussion about this issue from TypeScript's perspective.
Here's an example of how you're supposed to export subpath types according to Microsoft's module resolution guy.

It's a bit over my head right now, I wish I could explain exactly how it works. 🙂
Also the current package.json seems pretty deliberate so I could be totally wrong.

FWIW it seems like when the modern & upcoming module resolution is enabled, exports takes precedence and it becomes necessary to define the types there too. And it sounds like the new way will be the default eventually.

@cbbfcd
Copy link
Contributor

cbbfcd commented Feb 2, 2023

pr welcome 😄

@toerndev
Copy link
Author

toerndev commented Feb 2, 2023

pr welcome

Sure, done!
Wasn't sure whether it's the best solution or if you'd want it, but after thinking a bit I don't see what problems it could cause.
Feel free to close this. :-)

@molefrog
Copy link
Owner

molefrog commented Feb 6, 2023

@molefrog molefrog closed this as completed Feb 6, 2023
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

No branches or pull requests

3 participants