-
Notifications
You must be signed in to change notification settings - Fork 79
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
chore: add guard-for-in
eslint rule
#1210
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #1210 +/- ##
==========================================
- Coverage 77.60% 76.04% -1.57%
==========================================
Files 83 83
Lines 17311 17246 -65
Branches 1747 1739 -8
==========================================
- Hits 13434 13114 -320
- Misses 3841 4070 +229
- Partials 36 62 +26 ☔ View full report in Codecov by Sentry. |
Out of curiosity: Did you run into an actual problem or are you proposing the change because of the possible unexpected errors? |
I think there haven't been real problems so far, however, I think I've already read some time ago that using However, I've also noticed that there are several places where a pattern like for (const key in object) {
const value = object[key];
useKeyAndValue(key, value);
} is being used. In terms of readability and especially type safety, I think it is better to rather use something like for (const [key, value] of Object.entries(object)) {
useKeyAndValue(key, value);
} instead, which is encouraged by activating the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions/required changes below.
const el = properties[key]; | ||
// TODO: Use correct type for el | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
for (const [key, el] of Object.entries(properties) as [string, any]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PropertyElement
doesn't work here?
const el = properties[key]; | ||
// TODO: Use correct type for el | ||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
for (const [key, el] of Object.entries(properties) as [string, any]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same as above?
@@ -535,11 +535,11 @@ export default class OctetstreamCodec implements ContentCodec { | |||
} | |||
|
|||
result = result ?? Buffer.alloc(parseInt(parameters.length)); | |||
for (const propertyName in schema.properties) { | |||
// eslint-disable-next-line @typescript-eslint/no-explicit-any | |||
for (const [propertyName, propertySchema] of Object.entries(schema.properties) as [string, any]) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing TODO. can't we try to use the inferred type from the removed line below?
const propertySchema = schema.properties[propertyName];
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing TODO.
Thank you, should be fixed now :)
can't we try to use the inferred type from the removed line below?
const propertySchema = schema.properties[propertyName];
Unfortunately, the type of propertySchema
was any
here :/ DataSchema
seems to be defined like this at the moment in the wot-typescript-definitions
:
type DataSchema = { [key: string]: any; };
packages/td-tools/src/td-parser.ts
Outdated
property.readOnly ??= false; | ||
property.writeOnly ??= false; | ||
property.observable ??= false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new code is not exactly the same as the old one. The old one also corrected the type of the property. @danielpeintner should we keep it or the new version is better?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question. In theory for well-defined TDs it should not make any difference on the other hand the more complex "old" code fixes wrong types also. If it were me to decide I would stick with the old code.. but I do not have a very strong preference.
the same goes for actions and events
thing.properties[key].forms = []; | ||
thing.properties[key] = { | ||
// @ts-expect-error Here is a strange type mismatch present | ||
forms: [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it is correct, forms should contain at least one element with href defined, isn't it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, yeah, that is true. I have now found a potential solution for achieving a type-safe implementation here. Should there be an error thrown if the forms
array is empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See 4f2663f for an intial proposal.
|
||
thing.actions[key] = { | ||
// @ts-expect-error Here is a strange type mismatch present | ||
forms, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same comment as above.
Co-authored-by: Cristiano Aguzzi <relu91@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fine regarding the changes to mqtt package
(Not only) in the context of #1177, I noticed that some of the for loops use the
for ... in
syntax instead of thefor ... of
syntax. Apparently, the former style is discouraged and not recommended by eslint, for example (see https://eslint.org/docs/latest/rules/guard-for-in).This PR replaces the code lines in question and enforces the new style by activating the
guard-for-in
eslint rule.