-
Notifications
You must be signed in to change notification settings - Fork 40
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
ARM: add arm-resource-name-pattern
rule to allow disabling LintDiff ResourceNamePattern
rule
#359
Conversation
All changed packages have been documented. |
5769075
to
3e989be
Compare
You can try these changes at https://cadlplayground.z22.web.core.windows.net/typespec-azure/prs/359/ Check the website changes at https://tspwebsitepr.z22.web.core.windows.net/typespec-azure/prs/359/ |
1643029
to
65a18db
Compare
const statusCodes = new Set([...httpOp.responses.map((r) => r.statusCodes.toString())]); | ||
const expected = new Set(["204", "*"]); | ||
expected.add(isAsync ? "202" : "200"); | ||
root: (program: Program) => { |
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.
This is just a refactoring of this existing rule to be more efficient. It doesn't change the behavior.
if (pattern === undefined) { | ||
context.reportDiagnostic({ | ||
target: nameProperty, | ||
}); | ||
} |
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.
So, per the LintDiff rule it says it's also fine to apply the default ARM pattern here if one is not provided. We have a couple options:
- don't do that and just always throw this warning
- always apply the default if not specified, in which case this linter rule actually becomes a warning diagnostic and the logic would change
- provide an easy mechanism to provide the default pattern and have the error message tell people to use that (like we did for the error codes rule pointing to other templates).
@markcowl @timotheeguerin @johanste any thoughts on what is preferrable?
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.
It would be preferable (to me) if there was an implicit default. But I'm not sure how many resources adhere to the same constraints.
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.
That rule could also be an easy code fix candidate so user can auto fix
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.
@timotheeguerin do we have documentation on how to do that?
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.
https://typespec.io/docs/extending-typespec/linters#provide-a-codefix
For linter in particular
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 auto suppress code fix in the compiler is a simple one that is similar in the logic
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.
Also feels like adding a decorator on a node feels like a common code fix we should maybe build a common helper piece in the same way we have the update identfier codefix, don't need to do that in your pr but could use that as the base piece for it as a separate issue
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.
Agreed, a codefix with the default value is the best way to document this. In general, I think we should make a codefix an acceptance criterion for new linting rules, where that is possible.
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.
But, please, file an issue for adding the codefix for this, it is important we get this rule in.
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.
Filed issue: microsoft/typespec#3044
I put a local codefix here that we can replace when the global helper is available.
43af0a9
to
6e6f405
Compare
.chronus/changes/arm-resourceNamePatternRule-2024-2-4-21-52-56.md
Outdated
Show resolved
Hide resolved
if (pattern === undefined) { | ||
context.reportDiagnostic({ | ||
target: nameProperty, | ||
}); | ||
} |
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.
That rule could also be an easy code fix candidate so user can auto fix
2c47c86
to
3c071ec
Compare
packages/typespec-azure-resource-manager/src/rules/arm-resource-name-pattern.ts
Outdated
Show resolved
Hide resolved
3c071ec
to
05080c4
Compare
packages/typespec-azure-resource-manager/src/rules/arm-resource-name-pattern.ts
Outdated
Show resolved
Hide resolved
if (pattern === undefined) { | ||
context.reportDiagnostic({ | ||
target: nameProperty, | ||
}); | ||
} |
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.
Agreed, a codefix with the default value is the best way to document this. In general, I think we should make a codefix an acceptance criterion for new linting rules, where that is possible.
if (pattern === undefined) { | ||
context.reportDiagnostic({ | ||
target: nameProperty, | ||
}); | ||
} |
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.
But, please, file an issue for adding the codefix for this, it is important we get this rule in.
d5d8172
to
ba13810
Compare
packages/typespec-azure-resource-manager/src/rules/arm-resource-name-pattern.ts
Outdated
Show resolved
Hide resolved
39e45f6
to
9162849
Compare
packages/typespec-azure-resource-manager/src/rules/arm-resource-name-pattern.ts
Outdated
Show resolved
Hide resolved
40b98a5
to
f05e32f
Compare
…e-name-pattern.ts Co-authored-by: Mark Cowlishaw <[email protected]>
f05e32f
to
a4a565c
Compare
const resources = getArmResources(program); | ||
for (const resource of resources) { | ||
// find the name property | ||
const nameProperty = resource.typespecType.properties.get("name"); |
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.
This is likely to change soon, but is accurate for now
Closes https://github.com/Azure/typespec-azure-pr/issues/3903
REST API Specs (6 violations)
Azure/azure-rest-api-specs#28085
OpenAPI Validator PR
Azure/azure-openapi-validator#669