Skip to content
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

feat(Dpe 135): naming rules #85

Merged
merged 38 commits into from
Jul 17, 2024
Merged

feat(Dpe 135): naming rules #85

merged 38 commits into from
Jul 17, 2024

Conversation

EthanHonzikSPS
Copy link
Contributor

  • Created a ruleset schema
  • installed jest types
  • added a tsconfig.json such that JS files will be validated for type errors
  • updated the camel case rule to use the built in casing function instead of regex to get performance
  • Addressed all the comments on the confluence page
  • Updated documentation with links

@EthanHonzikSPS EthanHonzikSPS requested a review from a team as a code owner July 10, 2024 19:44
@EthanHonzikSPS
Copy link
Contributor Author

Performance:

Overall performance improved from 30 seconds down to 23 seconds to run the entire performance test suite. I suspect this is due to using the built in casing function instead of regex.

Problems:

Camel Case

Camel case rule has a very large impact on Identity-service with multi-hundred errors. Network-configuration-service has over 1000 errors. We will likely have to change the severity from error to warning.

General

Warnings had a large jump due to the various naming conventions network-configuration-service again had the largest jump with around 600 additional warnings from the original 254 warnings

@EthanHonzikSPS EthanHonzikSPS changed the title Dpe 135 naming rules feat: Dpe 135 naming rules Jul 12, 2024
@EthanHonzikSPS EthanHonzikSPS changed the title feat: Dpe 135 naming rules feat(Dpe 135): naming rules Jul 12, 2024
Out of scope for PR

Signed-off-by: Ethan Honzik <[email protected]>
Copy link
Contributor

@brandonsahadeo brandonsahadeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple of questions

rulesets/test/root.openapi.yml Outdated Show resolved Hide resolved
standards/naming.md Show resolved Hide resolved
Copy link
Contributor

@markdebeer markdebeer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me! Just a few copy/paste issues. As far as the impact test, we should chat as a team about whether we need to start leveraging the recommended property -> https://docs.stoplight.io/docs/spectral/0a73453054745-recommended-or-all

Copy link
Member

@travisgosselin travisgosselin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the impact specifically on network API related specs (ones that should be conforming already)?

rulesets/src/naming.ruleset.yml Show resolved Hide resolved
rulesets/src/naming.ruleset.yml Outdated Show resolved Hide resolved
rulesets/src/naming.ruleset.yml Outdated Show resolved Hide resolved
rulesets/src/naming.ruleset.yml Outdated Show resolved Hide resolved
rulesets/src/naming.ruleset.yml Show resolved Hide resolved
rulesets/src/naming.ruleset.yml Show resolved Hide resolved
@travisgosselin
Copy link
Member

Performance:

Overall performance improved from 30 seconds down to 23 seconds to run the entire performance test suite. I suspect this is due to using the built in casing function instead of regex.

Problems:

Camel Case

Camel case rule has a very large impact on Identity-service with multi-hundred errors. Network-configuration-service has over 1000 errors. We will likely have to change the severity from error to warning.

General

Warnings had a large jump due to the various naming conventions network-configuration-service again had the largest jump with around 600 additional warnings from the original 254 warnings

What was the original rule you were referring to with the regex for camelCase? I didn't see it in the comparison of naming.ruleset.yml...

@EthanHonzikSPS
Copy link
Contributor Author

What is the impact specifically on network API related specs (ones that should be conforming already)?

With camel case changed to a warning there's a couple additional errors that occur with the sps-invalid-created-date-time-type rule. Additionally there is a bit of uptick in warnings anywhere from 1 to 9. Most of these are camel case issues but there's a couple miscellaneous ones as well.

What was the original rule you were referring to with the regex for camelCase? I didn't see it in the comparison of naming.ruleset.yml...

sps-camel-case-properties regex when I first cloned it, This I'm now realizing was included in @brandonsahadeo's first commit to this branch and wasn't a part of main.

@travisgosselin
Copy link
Member

What is the impact specifically on network API related specs (ones that should be conforming already)?

With camel case changed to a warning there's a couple additional errors that occur with the sps-invalid-created-date-time-type rule. Additionally there is a bit of uptick in warnings anywhere from 1 to 9. Most of these are camel case issues but there's a couple miscellaneous ones as well.

OK as long as we feel confident that these are legit issues detected and are mistakes by the team then this is great. How many warnings do the camel case change generate on the network apis? Is it a lot?

What was the original rule you were referring to with the regex for camelCase? I didn't see it in the comparison of naming.ruleset.yml...

sps-camel-case-properties regex when I first cloned it, This I'm now realizing was included in @brandonsahadeo's first commit to this branch and wasn't a part of main.

ah OK makes more sense, was looking for it. So no real performance change against main then.

@EthanHonzikSPS
Copy link
Contributor Author

I discovered the camel case rule was failing properties with digits. After allowing digits there were no camel casing issues. As such I've changed it back to an error.
This is the performance and impact of the rules in their current state.
Picture1
Impact

@EthanHonzikSPS
Copy link
Contributor Author

PerfTestImpact
@brandonsahadeo Here's the performance test impact.

@EthanHonzikSPS EthanHonzikSPS merged commit cd1301c into main Jul 17, 2024
2 checks passed
@EthanHonzikSPS EthanHonzikSPS deleted the DPE-135-naming-rules branch July 17, 2024 19:02
SPSCommerce-VSTS-BOT pushed a commit that referenced this pull request Jul 17, 2024
# [1.12.0](v1.11.4...v1.12.0) (2024-07-17)

### Features

* **Dpe 135:** naming rules ([#85](#85)) ([cd1301c](cd1301c))
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants