feat: Add type exports to enable declaration: true in tsconfig.json - #1509
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
@osaton is attempting to deploy a commit to the next-intl Team on Vercel. A member of the Team first needs to authorize it. |
amannn
left a comment
amannn
left a comment
There was a problem hiding this comment.
Super cool, thanks a lot for looking into this!
| HrefOrHrefWithParams, | ||
| HrefOrUrlObjectWithParams, | ||
| QueryParams | ||
| } from '../shared/utils'; |
There was a problem hiding this comment.
Is there a way to get a list of which types need to be exported? Or was this rather trial & error?
Some of these types should have their names reconsidered in case we have to export them. Ideally, we wouldn't have to. In the past, I think I was able to work around exporting some types via ReturnType<typeof …> annotations at some places where I saw declaration errors.
There was a problem hiding this comment.
Unfortunately, it's just trial & error. At least I don't know of a better way to check them. That said, this approach led to some unnecessary exports which I’ve removed in my latest commit.
There was a problem hiding this comment.
Okay, thanks! I'll also verify the imports again once we can use example-app-router-playground to verify that declaration: true works.
| - "examples/*" | ||
| - "docs" | ||
| - 'packages/*' | ||
| - 'type-export-test' |
There was a problem hiding this comment.
example-app-router-playground is in fact already a good example that stress-tests all APIs of next-intl. Can we add a tsconfig.declaration.json there and add a lint task that calls tsc with that config?
That way we don't have to add a completely new app (each example adds some maintenance burden).
There was a problem hiding this comment.
Should we add some directory for export tests, or how should we approach this? example-app-router-playground already tests most things, but it does not cover export of every return type from the library.
There was a problem hiding this comment.
Which APIs did you find are not used in example-app-router-playground yet? If there are some, you can add e.g. a component in the src/components folder that uses the API. It doesn't even need to be imported anywhere, as this is just about ensuring tsc runs properly. But please check if they aren't already used somewhere 🙂.
There was a problem hiding this comment.
They are used, but not everything is exported. For example useTimeZone hook is only used inside components and as they only export JSX.Element, TypeScript does not have to try and export the return type of that function. But if you add something like:
export function useExport() {
return useTimeZone();
}You'll get the following error:
The inferred type of 'useExport' cannot be named without a reference to '../../../../packages/next-intl/node_modules/use-intl/dist/types/src/core/TimeZone'. This is likely not portable. A type annotation is necessary.
There was a problem hiding this comment.
Ah, gotcha! Do you think you can add a module to example-app-router-playground that contains all such cases along with a lint task for the declaration? I'd really like to avoid adding a new example.
example-app-router-playground already tests a bunch of functionality, might be handy also for the declaration test to ensure all of the demonstrated patterns work with this mode.
There was a problem hiding this comment.
The export tests are now located in example-app-router-playground. I updated the app's existing tsconfig.json with the declaration property, as it improves editor feedback.
I removed createSharedPathnamesNavigation and createLocalizedPathnamesNavigation from export tests since they are deprecated, and createNavigation covers both of those.
Feel free to make changes, if you'd like to tweak anything.
There was a problem hiding this comment.
Awesome, thanks a lot! Just had another look from my side and added a commit with some minor cleanup.
All good from my perspective, let's see if CI is happy too …
5682d28 to
afa3276
Compare
amannn
changed the title
declaration: true in tsconfig.json
…n` (amannn#1509) Re: <amannn#1014> Fix the type issues encountered when re-exporting types in a client application with `compilerOptions.declaration` set to `true`. This change addresses errors such as: > The inferred type of 'Link' cannot be named without a reference to '../node_modules/next-intl/dist/types/src/shared/types'. This is likely not portable. A type annotation is necessary.ts(2742) --------- Co-authored-by: Jan Amann <jan@amann.work>
2 participants
Re: #1014
Fix the type issues encountered when re-exporting types in a client application with
compilerOptions.declarationset totrue. This change addresses errors such as: