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

[tcgc] add linter rulesets framework #1208

Open
wants to merge 15 commits into
base: main
Choose a base branch
from
Open

Conversation

iscai-msft
Copy link
Contributor

@iscai-msft iscai-msft commented Jul 19, 2024

fixes #1147

@azure-sdk
Copy link
Collaborator

azure-sdk commented Jul 19, 2024

All changed packages have been documented.

  • @azure-tools/typespec-azure-rulesets
  • @azure-tools/typespec-client-generator-core
Show changes

@azure-tools/typespec-client-generator-core - feature ✏️

add linter rulesets to TCGC, for both generic and language-specific linter rules

@azure-tools/typespec-azure-rulesets - feature ✏️

add some tcgc rules to the list

},
},
"incorrect-client-format": {
"invalid-client-format": {
Copy link
Member

Choose a reason for hiding this comment

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

Is this actually used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it's used when we're checking the input of @clientFormat. Is this valid?

Copy link
Member

Choose a reason for hiding this comment

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

I don't see it used in main anymore, could it have been removed

@azure-sdk
Copy link
Collaborator

You can try these changes here

🛝 Playground 🌐 Website 📚 Next docs

1. Write the rule in `typespec-azure/packages/typespec-client-generator-core/src/rules/[rule-name].rule.ts
2. Add reference to the rule in the `rules` array in [`typespec-azure/packages/typespec-client-generator-core/src/linter.ts`][tcgc-linter]
- This will automatically add it to a ruleset called `:all` for `@azure-tools/typespec-client-generator-core`
3. Add the rule to the enable list for [`data-plane.ts`][data-plane-ruleset] and/or [`resource-manager.ts`][resource-manager-ruleset] in the [rulesets][rulesets] package. You can set `enable` to `false` here, if you want to delay enabling
Copy link
Member

Choose a reason for hiding this comment

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

Do we really want to have different rules for data plane and mgmt plane? I know we are less strict with mgmt plane, but aren't the recommendations the same for both?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's the current setup of azure-core-rulesets, where you explicitly list rules for the data plane and mgmt rulesets

Copy link
Member

Choose a reason for hiding this comment

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

there is some rules that management plane specific and some that shouldn't apply to mamangement plane. But the majority should apply to both

Copy link
Member

Choose a reason for hiding this comment

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

Do we have a single place to add a rule that applies to both or do we need to add the rule explicitly to both lists?


**If you are adding a language-specific rule**, you will also need this extra step 4. Add reference to the rule in the `[language]Rules` array in [`typespec-azure/packages/typespec-client-generator-core/src/linter.ts`][tcgc-linter]

For Azure generations then, all rules, including all language-specific rules, will be run on the specs.
Copy link
Member

Choose a reason for hiding this comment

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

I think we want to limit this to the Tier 1 languages not necessarily all languages? Should we specify this? I assume Go could add their own rules in here and those wouldn't apply unless generating Go even for azure?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's fair, let me update this to say that language-agnostic rules, and tier-1 languages will be run

**If you are adding a language-specific rule**, you will also need this extra step 4. Add reference to the rule in the `[language]Rules` array in [`typespec-azure/packages/typespec-client-generator-core/src/linter.ts`][tcgc-linter]

For Azure generations then, all rules, including all language-specific rules, will be run on the specs.
For unbranded generations, since we've added the rules into specific `best-practices:[language]` rulesets, you can explicitly specify a subset of rules in your `tsp-config.yaml`, i.e. if I only want Python best-practices, I could add this in my `tsp-config.yaml`:
Copy link
Member

Choose a reason for hiding this comment

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

This might create a bad situation where someone can turn off csharp rules but in reality they cannot. I think we might want to consider what flexibility a user would have over tcgc rules when running in azure context.

Copy link
Member

Choose a reason for hiding this comment

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

every azure service is enforced to have one of the 2 rules set enabled by the spec repo pipeline.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With rulesets, we have to give users the ability to turn them off because they are ultimately warnings. After talking with @timotheeguerin, you can't have error linter rules, only warnings. If there is a case where you explicitly want to error in csharp for a csharp-specific issue, the csharp emitter itself can throw a fatal error with reportDiagnostic, but the fatal error should have an analog in the linter warnings in tcgc that says "if you do this in csharp and ignore me, the csharp emitter will fail"

Available ruleSets:

- `@azure-tools/typespec-client-generator-core/all`
- `@azure-tools/typespec-client-generator-core/best-practices:csharp`
Copy link
Member

Choose a reason for hiding this comment

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

What does best practice mean here? Does it mean this is optional? If so is there another category which is not optional?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

best practices is what I've called the ruleset for now, open to suggestions! I think the advice from the typespec team has been to use the word "best-practices", @timotheeguerin is this correct?

Copy link
Member

Choose a reason for hiding this comment

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

Aren't these rulesets optional and can be opted out?

Copy link
Member

Choose a reason for hiding this comment

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

oh I don't think we have a strong opinion on that name, we just have a placeholder @typespec/best-practices package that would contain misc linter to write good typespec.

I would say name this however makes the most sense. But I would note that I don't think this really should spend too much time on this as for all of azure they MUST use either the data-plane or resource-manager ruleset in teh spec repo. And I assume all those rules for all those language will be enabled.

I expect those more targeted ruleset might be more useful when we have the non azure version of tcgc(e.g. @typespec/client) where external customer might decide which language they care about.


Available ruleSets:

- `@azure-tools/typespec-client-generator-core/all`
Copy link
Member

Choose a reason for hiding this comment

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

I am not sure all would ever be useful when considering non tier 1 languages as well as required rules vs best practices? Should we be a bit more granular on what all means?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

all isn't a specificly-defined ruleset, it's the standard name for all of the rules existing in a package

Available ruleSets:

- `@azure-tools/typespec-client-generator-core/all`
- `@azure-tools/typespec-client-generator-core/best-practices:csharp`
Copy link
Member

Choose a reason for hiding this comment

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

Aren't these rulesets optional and can be opted out?

| Name | Description |
| -------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `@azure-tools/typespec-client-generator-core/require-client-suffix` | Client names should end with 'Client'. |
| `@azure-tools/typespec-client-generator-core/property-name-conflict` | Avoid naming conflicts between a property and a model of the same name. |
Copy link
Member

Choose a reason for hiding this comment

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

Is this a required rule or is it a recommendation to avoid property and model having the same name.

Copy link
Member

Choose a reason for hiding this comment

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

all rules are in a sense optional its up to the user to enable them(directly or via a ruleset). For azure specs we require that the data-plane or resource-manager ruleset is used.

1. Write the rule in `typespec-azure/packages/typespec-client-generator-core/src/rules/[rule-name].rule.ts
2. Add reference to the rule in the `rules` array in [`typespec-azure/packages/typespec-client-generator-core/src/linter.ts`][tcgc-linter]
- This will automatically add it to a ruleset called `:all` for `@azure-tools/typespec-client-generator-core`
3. Add the rule to the enable list for [`data-plane.ts`][data-plane-ruleset] and/or [`resource-manager.ts`][resource-manager-ruleset] in the [rulesets][rulesets] package. You can set `enable` to `false` here, if you want to delay enabling
Copy link
Member

Choose a reason for hiding this comment

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

Do we have a single place to add a rule that applies to both or do we need to add the rule explicitly to both lists?

1. Write the rule in `typespec-azure/packages/typespec-client-generator-core/src/rules/[rule-name].rule.ts
2. Add reference to the rule in the `rules` array in [`typespec-azure/packages/typespec-client-generator-core/src/linter.ts`][tcgc-linter]
- This will automatically add it to a ruleset called `:all` for `@azure-tools/typespec-client-generator-core`
3. Add the rule to the enable list for [`data-plane.ts`][data-plane-ruleset] and/or [`resource-manager.ts`][resource-manager-ruleset] in the [rulesets][rulesets] package. You can set `enable` to `false` here, if you want to delay enabling
Copy link
Member

Choose a reason for hiding this comment

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

I don't see step 3 done in this PR. Will this be added in a follow-up PR?

import { requireClientSuffixRule } from "../../src/rules/require-client-suffix.rule.js";
import { createSdkTestRunner } from "../test-host.js";

describe("typespec-client-generator-core: require-client-suffix", () => {
Copy link
Member

Choose a reason for hiding this comment

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

nit: no need to add those top level describe with vitest, they just add extra nesting in the UI

});

// TODO: reenable when rule is moved to tcgc and can resolve if clientName was set
it.skip(`is valid if conflict resolved through @clientName("newName", "csharp")`, async () => {
Copy link
Member

Choose a reason for hiding this comment

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

i think those todo can be actioned on now?

Copy link
Member

Choose a reason for hiding this comment

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

should you be removing that rule from azure core too now?

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.

[tcgc] adding linter rules for languages to tcgc
5 participants