-
Notifications
You must be signed in to change notification settings - Fork 291
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
style(cmd-api-server): fix any linter in getOrCreateWebServices() #2751
style(cmd-api-server): fix any linter in getOrCreateWebServices() #2751
Conversation
Signed-off-by: D.Yogesh <[email protected]>
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.
Thankyou for the PR, @Yogesh01000100
This looks good to me !
…ervices() This addresses the shortcomings of the linter fix provided in hyperledger-cacti#2751, which uses unchecked casts to the linter warnings go away. With the fix of hyperledger-cacti#2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on hyperledger-cacti#2751 Depends on hyperledger-cacti#2754 Signed-off-by: Peter Somogyvari <[email protected]>
… from OAS This addresses the shortcomings of the linter fix provided in hyperledger-cacti#2751, which uses unchecked casts to the linter warnings go away. With the fix of hyperledger-cacti#2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on hyperledger-cacti#2751 Depends on hyperledger-cacti#2754 Signed-off-by: Peter Somogyvari <[email protected]>
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.
@Yogesh01000100 Thank you! This is fine to fix the linter warnings themselves so LGTM (just commenting instead of explicit approval to avoid accidental pre-quorum merge).
For fixing it with runtime type validation baked in, please look at the 2 PRs I just opened We'll merge your first because the linter fixes here are legit and then my 2 PRs coming after it will extend the fix with the runtime type validation. This is just an FYI in case you have the time & willingness to look into the extended solution.
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.
LGTM
… from OAS This addresses the shortcomings of the linter fix provided in hyperledger-cacti#2751, which uses unchecked casts to the linter warnings go away. With the fix of hyperledger-cacti#2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on hyperledger-cacti#2751 Depends on hyperledger-cacti#2754 Signed-off-by: Peter Somogyvari <[email protected]>
… from OAS This addresses the shortcomings of the linter fix provided in hyperledger-cacti#2751, which uses unchecked casts to the linter warnings go away. With the fix of hyperledger-cacti#2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on hyperledger-cacti#2751 Depends on hyperledger-cacti#2754 Signed-off-by: Peter Somogyvari <[email protected]>
… from OAS This addresses the shortcomings of the linter fix provided in #2751, which uses unchecked casts to the linter warnings go away. With the fix of #2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on #2751 Depends on #2754 Signed-off-by: Peter Somogyvari <[email protected]>
… from OAS This addresses the shortcomings of the linter fix provided in hyperledger-cacti#2751, which uses unchecked casts to the linter warnings go away. With the fix of hyperledger-cacti#2751, at runtime, the possibility of a crash is still there exactly as before, but it has silenced the linter about calling that possibility out. We now use a type guard to check the type of the object before casting it and therefore ensure that at runtime the cast will not produce a crash. [skip ci] Depends on hyperledger-cacti#2751 Depends on hyperledger-cacti#2754 Signed-off-by: Peter Somogyvari <[email protected]>
Description:
This pull request addresses issue #2676 by fixing an Unexpected any linter warning in the getOrCreateWebServices() method of the ApiServer class. The warning occurred due to a typecast using (app as any).
Changes:
Replaced (app as any) with (app as express.Express)[httpVerbPrometheus as keyof express.Express](httpPathPrometheus, prometheusExporterHandler);
Importance of keyof:
The use of keyof here is crucial because it ensures that httpVerbPrometheus and httpVerb are treated as the valid key of the express.Express type. This is necessary because HTTP verbs, like GET, POST, PUT etc... should be treated as keys within the express.Express type. By casting httpVerbPrometheus as keyof express.Express, we enforce type safety and prevent potential runtime errors that could occur if an invalid HTTP verb is used. In essence, it ensures that only valid HTTP verbs are accepted, improving the robustness of the code.
Benefits:
This change enhances code readability and maintainability using appropriate types and expressions.