What is the current behavior?
Formatting relies on hardcoded patterns for languages in format/private/format.sh. Users who wish to customize the language patterns, perhaps to register an internal convention for a file pattern must patch this file.
In our case, we use an OWNERS file format based on the Kubernetes convention and register OWNERS as a YAML pattern with the following patch:
diff --git a/format/private/format.sh b/format/private/format.sh
index 7d4d7fadab..9a68ab848b 100755
--- a/format/private/format.sh
+++ b/format/private/format.sh
@@ -147,7 +147,7 @@
'TSX') patterns=('*.tsx') ;;
'TypeScript') patterns=('*.ts' '*.cts' '*.mts') ;;
'Vue') patterns=('*.vue') ;;
- 'YAML') patterns=('*.yml' '*.yaml' '.clang-format' '.clang-tidy' '.gemrc') ;;
+ 'YAML') patterns=('*.yml' '*.yaml' '.clang-format' '.clang-tidy' '.gemrc' 'OWNERS') ;;
# Note: https://github.com/github-linguist/linguist/blob/559a6426942abcae16b6d6b328147476432bf6cb/lib/linguist/languages.yml#L7767-L7882
# has a giant list of patterns. We arbitrarily choose some "common" ones.
'XML') patterns=('*.xml' '*.xsd') ;;
This patch wouldn't be appropriate to upstream, so we're left indefinitely maintaining a patch on top of rules_lint releases.
Describe the feature
Users with the above use case are likely already managing these file associations in .gitattributes for GitHub syntax highlighting. In our case, for the OWNERS example, we have the folllowing in our .gitattributes file:
OWNERS linguist-language=YAML
The feature request would be to update format/private/format.sh to query .gitattributes for language patterns in ls-files to avoid patching the script.
The format script already queries .gitattributes for rules-lint-ignored, so this change would be in the spirit of the existing implementation and would also honor the disable_git_attribute_checks flag.
I propose that we support two conventions for git attributes:
- A new
rules-lint-language attribute for users who wish to be explicit
- Repurpose the existing
linguist-language to automatically opt-in GitHub language mappings
What is the current behavior?
Formatting relies on hardcoded patterns for languages in
format/private/format.sh. Users who wish to customize the language patterns, perhaps to register an internal convention for a file pattern must patch this file.In our case, we use an OWNERS file format based on the Kubernetes convention and register
OWNERSas aYAMLpattern with the following patch:This patch wouldn't be appropriate to upstream, so we're left indefinitely maintaining a patch on top of
rules_lintreleases.Describe the feature
Users with the above use case are likely already managing these file associations in
.gitattributesfor GitHub syntax highlighting. In our case, for the OWNERS example, we have the folllowing in our.gitattributesfile:The feature request would be to update
format/private/format.shto query.gitattributesfor language patterns inls-filesto avoid patching the script.The format script already queries
.gitattributesforrules-lint-ignored, so this change would be in the spirit of the existing implementation and would also honor thedisable_git_attribute_checksflag.I propose that we support two conventions for git attributes:
rules-lint-languageattribute for users who wish to be explicitlinguist-languageto automatically opt-in GitHub language mappings