Change from using "any" to "unknown" for unspecified types. #625
Conversation
In accordance with Typescript guides the use of the "any" type doesn't enforce many guarantees, it will match any type. In situations where the type is unspecified it is better to use the "unknown" which is closely related to the "any" type but requires a type assertion or control flow based narrowing before the type can be used. The use of the "unknown" type seems much more appropriate to use then "any" for these cases. See: https://devblogs.microsoft.com/typescript/announcing-typescript-3-0-rc-2/#the-unknown-type For more details.
Codecov Report
@@ Coverage Diff @@
## main #625 +/- ##
==========================================
+ Coverage 88.53% 90.25% +1.71%
==========================================
Files 9 10 +1
Lines 349 390 +41
Branches 123 141 +18
==========================================
+ Hits 309 352 +43
- Misses 37 38 +1
+ Partials 3 0 -3
Continue to review full report at Codecov.
|
|
I’m actually starting to second-guess this PR. Though I do think |
|
Hi @drwpow, I appreciate your reluctance to "break" things for users. While this change is increasing the safety of the generated interfaces it doesn't really do anything "wrong". If people are already relying on the behavior of "any" in their code, they're at risk right now of getting a type they don't actually expect. With "unknown", they need to be explicit with their types. This goes back to the Robustness Principal. This change matters more for implementers of OpenAPI interfaces compared to clients. If you're sending data the use of "any" is no big deal because it is not your responsibility to handle the data (you're merely sending it on), but if you're the server/implementor of the OpenAPI interface it matters quite a bit. It doesn't seem to me that many people use Rusty |
|
@rustyconover generally I'm in favor of using to get around this issue you could put this functionality behind a flag, which can then be removed with the next major bump. |
|
I'd like to voice my support for this PR as well. I'm in the process of investigating writing a custom formatter to remove |
|
Sorry for the delay on this—I had not had time the past few months to properly maintain the project. I will make this change in #769 and it will go out for the next release! And though this PR won’t be merged I’d still like to attribute credit for this code-writing and improvement. |
|
@all-contributors please add @rustyconover for code |
|
I've put up a pull request to add @rustyconover! 🎉 |
In accordance with Typescript guides the use of the "any" type doesn't
enforce many guarantees, it will match any type. In situations where
the type is unspecified it is better to use the "unknown" which is
closely related to the "any" type but requires a type assertion or
control flow based narrowing before the type can be used. The use of
the "unknown" type seems much more appropriate to use then "any" for
these cases.
See:
https://devblogs.microsoft.com/typescript/announcing-typescript-3-0-rc-2/#the-unknown-type
For more details.