You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, we don't have a unified approach for throwing linter warnings that language SDKs will run into. Since we want these linter warnings to come up during definition time, we agree that it would be best to include these linter warnings in tcgc. That being said, we should still have a mapping for what warnings apply to which languages. This mapping will be internal, so we can figure out when to throw, and properly use information from scope to determine whether the issue has been fixed. One idea is to have an exclusion and inclusion list for languages
When generating azure, we want to run linter warnings for all languages, since it is within Azure guidelines to generate all major languages. When generating unbranded, we will only run language-specific warnings. This is because we don't want to force an unbranded person only generating c# to have to deal with python-specific warnings.
I'll start off by designing a framework that will allow easy mapping to languages, and easily allow languages to opt in or opt out of rules. One good rule of thumb is, if it's a warning log, it will be a good idea to move it to be an actual linter warning
Check that this issue is about the Azure libraries for typespec. For feature request in the typespec language or core libraries file it in the TypeSpec repo
Clear and concise description of the problem
Currently, we don't have a unified approach for throwing linter warnings that language SDKs will run into. Since we want these linter warnings to come up during definition time, we agree that it would be best to include these linter warnings in tcgc. That being said, we should still have a mapping for what warnings apply to which languages. This mapping will be internal, so we can figure out when to throw, and properly use information from
scope
to determine whether the issue has been fixed. One idea is to have an exclusion and inclusion list for languagesWhen generating
azure
, we want to run linter warnings for all languages, since it is within Azure guidelines to generate all major languages. When generatingunbranded
, we will only run language-specific warnings. This is because we don't want to force an unbranded person only generating c# to have to deal with python-specific warnings.I'll start off by designing a framework that will allow easy mapping to languages, and easily allow languages to opt in or opt out of rules. One good rule of thumb is, if it's a warning log, it will be a good idea to move it to be an actual linter warning
Checklist
The text was updated successfully, but these errors were encountered: