Convert warning package to TypeScript

[jpstevens]

What?

This PR converts the warning package to TypeScript.

Why?

Ensures package is fully type checked.

How?

• converted files to .ts
• added explicit return types for functions in index and utils files

Testing Instructions

npm run test:unit -- packages/warning tests pass npm run build:package-types returns a zero exit code

[github-actions[bot]]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: jpstevens <[email protected]>
Co-authored-by: youknowriad <[email protected]>
Co-authored-by: sirreal <[email protected]>
Co-authored-by: jsnajdr <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions[bot]]

:wave: Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @jpstevens! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

[youknowriad]

Thanks for your help typing all these packages.

I thought this package was already fully typed. Is renaming to ts files necessary?

@sirreal Can you help me navigate this a bit :P

[sirreal]

I thought this package was already fully typed. Is renaming to ts files necessary?

Changing the file extension doesn't change much here. This package is typechecked, types are generated for the package, and no complex types are necessary that can't be easily expressed in JSDoc.

The type of the public API of the current version this package can be found here: https://unpkg.com/browse/@wordpress/[email protected]/build-types/index.d.ts

That would be exactly the same.

The explicit return type annotations added to the two functions might be a nice change, they're both inferred to be the same thing, but some would argue that adding those annotations is a good thing.

[youknowriad]

I've been thinking about this PR. While I see some value in it, I'm not sure that we should move forward with it. It has no real impact on the generated types or whether the package is fully typed. It's really a code style change.

And the thing is that while for this package it's fine, it may create a snowball effect for other packages and we'll find our selves spending time rewriting JS to TS for a lot of code and reviewing a lot of code for a small benefit.

[jsnajdr]

My main argument in favor of TS conversions like this is that the JSDoc type annotations are a rather obscure feature and most people are not familiar with them. I guess that many would be surprised to learn that such a thing even exists.

Who is really fluent in knowing that @template {string} T means <T extends string> or what's the difference between @prop {string?} and @prop {string=}? I believe the native syntax is more readable for virtually everyone, and is much better searchable in docs, Stack Overflow questions etc.

[youknowriad]

I don't feel that strongly, so I can be convinced, happy to hear other opinions.

[sirreal]

👋 @jpstevens If you'll update this PR on the latest trunk and remove types from JSDoc, we can likely give this a final review and land it.