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

ARM: add arm-resource-name-pattern rule to allow disabling LintDiff ResourceNamePattern rule #359

Merged
merged 15 commits into from
Mar 28, 2024

Conversation

tjprescott
Copy link
Member

@tjprescott tjprescott commented Mar 4, 2024

@azure-sdk
Copy link
Collaborator

azure-sdk commented Mar 4, 2024

All changed packages have been documented.

@tjprescott tjprescott force-pushed the arm/resourceNamePatternRule branch 2 times, most recently from 5769075 to 3e989be Compare March 4, 2024 21:55
@azure-sdk
Copy link
Collaborator

@tjprescott tjprescott force-pushed the arm/resourceNamePatternRule branch 2 times, most recently from 1643029 to 65a18db Compare March 5, 2024 19:11
@tjprescott tjprescott marked this pull request as ready for review March 5, 2024 19:26
const statusCodes = new Set([...httpOp.responses.map((r) => r.statusCodes.toString())]);
const expected = new Set(["204", "*"]);
expected.add(isAsync ? "202" : "200");
root: (program: Program) => {
Copy link
Member Author

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.

Comment on lines 27 to 68
if (pattern === undefined) {
context.reportDiagnostic({
target: nameProperty,
});
}
Copy link
Member Author

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:

  1. don't do that and just always throw this warning
  2. always apply the default if not specified, in which case this linter rule actually becomes a warning diagnostic and the logic would change
  3. 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?

Copy link
Member

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.

Copy link
Member

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

Copy link
Member Author

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?

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

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

Copy link
Member

@timotheeguerin timotheeguerin Mar 13, 2024

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

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

Comment on lines 27 to 68
if (pattern === undefined) {
context.reportDiagnostic({
target: nameProperty,
});
}
Copy link
Member

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

@tjprescott tjprescott force-pushed the arm/resourceNamePatternRule branch 2 times, most recently from 2c47c86 to 3c071ec Compare March 11, 2024 20:52
Comment on lines 27 to 68
if (pattern === undefined) {
context.reportDiagnostic({
target: nameProperty,
});
}
Copy link
Member

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.

Comment on lines 27 to 68
if (pattern === undefined) {
context.reportDiagnostic({
target: nameProperty,
});
}
Copy link
Member

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.

@tjprescott tjprescott force-pushed the arm/resourceNamePatternRule branch 2 times, most recently from 40b98a5 to f05e32f Compare March 28, 2024 17:48
const resources = getArmResources(program);
for (const resource of resources) {
// find the name property
const nameProperty = resource.typespecType.properties.get("name");
Copy link
Member

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

@tjprescott tjprescott merged commit 8d9d99a into main Mar 28, 2024
16 checks passed
@tjprescott tjprescott deleted the arm/resourceNamePatternRule branch March 28, 2024 21:20
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.

5 participants