{"id":13358645,"url":"https://github.com/styrainc/regal","last_synced_at":"2025-05-16T05:05:35.646Z","repository":{"id":173382757,"uuid":"592365615","full_name":"StyraInc/regal","owner":"StyraInc","description":"Regal is a linter and language server for Rego, bringing your policy development experience to the next level!","archived":false,"fork":false,"pushed_at":"2025-05-12T12:25:05.000Z","size":7827,"stargazers_count":297,"open_issues_count":108,"forks_count":41,"subscribers_count":12,"default_branch":"main","last_synced_at":"2025-05-12T13:34:36.885Z","etag":null,"topics":["code-quality","language-server","linter","lsp","magnificent","opa","open-policy-agent","policy-as-code","rego","static-analysis"],"latest_commit_sha":null,"homepage":"https://docs.styra.com/regal","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/StyraInc.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"docs/CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"docs/CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":"docs/SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2023-01-23T15:23:06.000Z","updated_at":"2025-05-12T12:25:07.000Z","dependencies_parsed_at":"2023-10-27T22:41:06.856Z","dependency_job_id":"565b1216-2d2e-48b7-a676-42227d22440c","html_url":"https://github.com/StyraInc/regal","commit_stats":{"total_commits":796,"total_committers":34,"mean_commits":23.41176470588235,"dds":0.4623115577889447,"last_synced_commit":"6716d37742ea31b884c1d4ff9992333149ef2176"},"previous_names":["styrainc/regal"],"tags_count":55,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StyraInc%2Fregal","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StyraInc%2Fregal/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StyraInc%2Fregal/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/StyraInc%2Fregal/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/StyraInc","download_url":"https://codeload.github.com/StyraInc/regal/tar.gz/refs/heads/main","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":253753073,"owners_count":21958829,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["code-quality","language-server","linter","lsp","magnificent","opa","open-policy-agent","policy-as-code","rego","static-analysis"],"created_at":"2024-07-29T21:03:40.652Z","updated_at":"2025-05-16T05:05:35.635Z","avatar_url":"https://github.com/StyraInc.png","language":"Go","funding_links":[],"categories":["Programming Languages"],"sub_categories":[],"readme":"# Regal\n\n[![Build Status](https://github.com/styrainc/regal/workflows/Build/badge.svg?branch=main)](https://github.com/styrainc/regal/actions)\n![OPA v1.4.2](https://openpolicyagent.org/badge/v1.4.2)\n[![codecov](https://codecov.io/github/StyraInc/regal/graph/badge.svg?token=EQK01YF3X3)](https://codecov.io/github/StyraInc/regal)\n[![Downloads](https://img.shields.io/github/downloads/styrainc/regal/total.svg)](https://github.com/StyraInc/regal/releases)\n\nRegal is a linter and language server for [Rego](https://www.openpolicyagent.org/docs/latest/policy-language/), making\nyour Rego magnificent, and you the ruler of rules!\n\nWith its extensive set of linter rules, documentation and editor integrations, Regal is the perfect companion for policy\ndevelopment, whether you're an experienced Rego developer or just starting out.\n\n\u003cimg\n  src=\"/docs/assets/regal-banner.png\"\n  alt=\"illustration of a viking representing the Regal logo\"\n  width=\"150px\" /\u003e\n\n\u003e regal\n\u003e\n\u003e adj : of notable excellence or magnificence : splendid\n\n\\- [Merriam Webster](https://www.merriam-webster.com/dictionary/regal)\n\n## Goals\n\n- Deliver an outstanding policy development experience by providing the best possible tools for that purpose\n- Identify common mistakes, bugs and inefficiencies in Rego policies, and suggest better approaches\n- Provide advice on [best practices](https://github.com/StyraInc/rego-style-guide), coding style, and tooling\n- Allow users, teams and organizations to enforce custom rules on their policy code\n\n## What People Say About Regal\n\n\u003e I really like that at each release of Regal I learn something new!\n\u003e Of all the linters I'm exposed to, Regal is probably the most instructive one.\n\n— Leonardo Taccari, [NetBSD](https://www.netbsd.org/)\n\n\u003e Reviewing the Regal rules documentation. Pure gold.\n\n— Dima Korolev, [Miro](https://miro.com/)\n\n\u003e Such an awesome project!\n\n— Shawn McGuire, [Atlassian](https://www.atlassian.com/)\n\n\u003e I am really impressed with Regal. It has helped me write more expressive and deterministic Rego.\n\n— Jimmy Ray, [Boeing](https://www.boeing.com/)\n\nSee the [adopters](/docs/adopters.md) file for more Regal users.\n\n## Getting Started\n\n### Download Regal\n\n**MacOS and Linux**\n```shell\nbrew install styrainc/packages/regal\n```\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003cstrong\u003eOther Installation Options\u003c/strong\u003e\u003c/summary\u003e\n\nPlease see [Packages](https://docs.styra.com/regal/adopters#packaging)\nfor a list of package repositories which distribute Regal.\n\nManual installation commands:\n\n**MacOS (Apple Silicon)**\n```shell\ncurl -L -o regal \"https://github.com/StyraInc/regal/releases/latest/download/regal_Darwin_arm64\"\n```\n\n**MacOS (x86_64)**\n```shell\ncurl -L -o regal \"https://github.com/StyraInc/regal/releases/latest/download/regal_Darwin_x86_64\"\n```\n\n**Linux (x86_64)**\n```shell\ncurl -L -o regal \"https://github.com/StyraInc/regal/releases/latest/download/regal_Linux_x86_64\"\nchmod +x regal\n```\n\n**Windows**\n```shell\ncurl.exe -L -o regal.exe \"https://github.com/StyraInc/regal/releases/latest/download/regal_Windows_x86_64.exe\"\n```\n\n**Docker**\n```shell\ndocker pull ghcr.io/styrainc/regal:latest\n```\n\nSee all versions, and checksum files, at the Regal [releases](https://github.com/StyraInc/regal/releases/) page, and\npublished Docker images at the [packages](https://github.com/StyraInc/regal/pkgs/container/regal) page.\n\u003c/details\u003e\n\n### Try it out!\n\nFirst, author some Rego!\n\n**policy/authz.rego**\n```rego\npackage authz\n\ndefault allow = false\n\nallow if {\n    isEmployee\n    \"developer\" in input.user.roles\n}\n\nisEmployee if regex.match(\"@acmecorp\\\\.com$\", input.user.email)\n```\n\nNext, run `regal lint` pointed at one or more files or directories to have them linted.\n\n```shell\nregal lint policy/\n```\n\u003c!-- markdownlint-capture --\u003e\n\u003c!-- markdownlint-disable MD010 --\u003e\n```text\nRule:         \tnon-raw-regex-pattern\nDescription:  \tUse raw strings for regex patterns\nCategory:     \tidiomatic\nLocation:     \tpolicy/authz.rego:12:27\nText:         \tisEmployee if regex.match(\"@acmecorp\\\\.com$\", input.user.email)\nDocumentation:\thttps://docs.styra.com/regal/rules/idiomatic/non-raw-regex-pattern\n\nRule:         \tuse-assignment-operator\nDescription:  \tPrefer := over = for assignment\nCategory:     \tstyle\nLocation:     \tpolicy/authz.rego:5:1\nText:         \tdefault allow = false\nDocumentation:\thttps://docs.styra.com/regal/rules/style/use-assignment-operator\n\nRule:         \tprefer-snake-case\nDescription:  \tPrefer snake_case for names\nCategory:     \tstyle\nLocation:     \tpolicy/authz.rego:12:1\nText:         \tisEmployee if regex.match(\"@acmecorp\\\\.com$\", input.user.email)\nDocumentation:\thttps://docs.styra.com/regal/rules/style/prefer-snake-case\n\n1 file linted. 3 violations found.\n```\n\u003c!-- markdownlint-restore --\u003e\n\u003cbr /\u003e\n\n\u003e **Note**\n\u003e If you're running Regal on an existing policy library, you may want to disable the `style` category initially, as it\n\u003e will likely generate a lot of violations. You can do this by passing the `--disable-category style` flag to\n\u003e `regal lint`.\n\n### Using Regal in Your Editor\n\nLinting from the command line is a great way to get started with Regal, and even for some experienced developers\nthe preferred way to work with the linter. However, not only is Regal a linter, but a full-fledged development\ncompanion for Rego development!\n\nIntegrating Regal in your favorite editor means you'll get immediate feedback from the linter as you work on your\npolicies. More than that, it'll unlock a whole new set of features that leverage Regal's\n[language server](#regal-language-server), like context-aware completion suggestions, informative tooltips on hover,\nor go-to-definition.\n\nElevate your policy development experience with Regal in VS Code, Neovim, Zed, Helix\nand more on our [Editor Support page](https://docs.styra.com/regal/editor-support)!\n\nTo learn more about the features provided by the Regal language server, see the\n[Language Server](https://docs.styra.com/regal/language-server) page.\n\n### Using Regal in Your Build Pipeline\n\nTo ensure Regal's rules are enforced consistently in your project or organization,\nwe've made it easy to run Regal as part of your builds.\nSee the docs on [Using Regal in your build pipeline](./docs/cicd.md) to learn more\nabout how to set up Regal to lint your policies on every commit or pull request.\n\n## Rules\n\nRegal comes with a set of built-in rules, grouped by category.\n\n- **bugs**: Common mistakes, potential bugs and inefficiencies in Rego policies.\n- **custom**: Custom, rules where enforcement can be adjusted to match your preferences.\n- **idiomatic**: Suggestions for more idiomatic constructs.\n- **imports**: Best practices for imports.\n- **style**: [Rego Style Guide](https://github.com/StyraInc/rego-style-guide) rules.\n- **testing**: Rules for testing and development.\n\nThe following rules are currently available:\n\n\u003c!-- RULES_TABLE_START --\u003e\n\n|  Category   |                                                  Title                                                  |                        Description                        |\n|-------------|---------------------------------------------------------------------------------------------------------|-----------------------------------------------------------|\n| bugs        | [annotation-without-metadata](https://docs.styra.com/regal/rules/bugs/annotation-without-metadata)      | Annotation without metadata                               |\n| bugs        | [argument-always-wildcard](https://docs.styra.com/regal/rules/bugs/argument-always-wildcard)            | Argument is always a wildcard                             |\n| bugs        | [constant-condition](https://docs.styra.com/regal/rules/bugs/constant-condition)                        | Constant condition                                        |\n| bugs        | [deprecated-builtin](https://docs.styra.com/regal/rules/bugs/deprecated-builtin)                        | Avoid using deprecated built-in functions                 |\n| bugs        | [duplicate-rule](https://docs.styra.com/regal/rules/bugs/duplicate-rule)                                | Duplicate rule                                            |\n| bugs        | [if-empty-object](https://docs.styra.com/regal/rules/bugs/if-empty-object)                              | Empty object following `if`                               |\n| bugs        | [if-object-literal](https://docs.styra.com/regal/rules/bugs/if-object-literal)                          | Object literal following `if`                             |\n| bugs        | [import-shadows-rule](https://docs.styra.com/regal/rules/bugs/import-shadows-rule)                      | Import shadows rule                                       |\n| bugs        | [impossible-not](https://docs.styra.com/regal/rules/bugs/impossible-not)                                | Impossible `not` condition                                |\n| bugs        | [inconsistent-args](https://docs.styra.com/regal/rules/bugs/inconsistent-args)                          | Inconsistently named function arguments                   |\n| bugs        | [internal-entrypoint](https://docs.styra.com/regal/rules/bugs/internal-entrypoint)                      | Entrypoint can't be marked internal                       |\n| bugs        | [invalid-metadata-attribute](https://docs.styra.com/regal/rules/bugs/invalid-metadata-attribute)        | Invalid attribute in metadata annotation                  |\n| bugs        | [leaked-internal-reference](https://docs.styra.com/regal/rules/bugs/leaked-internal-reference)          | Outside reference to internal rule or function            |\n| bugs        | [not-equals-in-loop](https://docs.styra.com/regal/rules/bugs/not-equals-in-loop)                        | Use of != in loop                                         |\n| bugs        | [redundant-existence-check](https://docs.styra.com/regal/rules/bugs/redundant-existence-check)          | Redundant existence check                                 |\n| bugs        | [redundant-loop-count](https://docs.styra.com/regal/rules/bugs/redundant-loop-count)                    | Redundant count before loop                               |\n| bugs        | [rule-assigns-default](https://docs.styra.com/regal/rules/bugs/rule-assigns-default)                    | Rule assigned its default value                           |\n| bugs        | [rule-named-if](https://docs.styra.com/regal/rules/bugs/rule-named-if)                                  | Rule named \"if\"                                           |\n| bugs        | [rule-shadows-builtin](https://docs.styra.com/regal/rules/bugs/rule-shadows-builtin)                    | Rule name shadows built-in                                |\n| bugs        | [sprintf-arguments-mismatch](https://docs.styra.com/regal/rules/bugs/sprintf-arguments-mismatch)        | Mismatch in `sprintf` arguments count                     |\n| bugs        | [time-now-ns-twice](https://docs.styra.com/regal/rules/bugs/time-now-ns-twice)                          | Repeated calls to `time.now_ns`                           |\n| bugs        | [top-level-iteration](https://docs.styra.com/regal/rules/bugs/top-level-iteration)                      | Iteration in top-level assignment                         |\n| bugs        | [unassigned-return-value](https://docs.styra.com/regal/rules/bugs/unassigned-return-value)              | Non-boolean return value unassigned                       |\n| bugs        | [unused-output-variable](https://docs.styra.com/regal/rules/bugs/unused-output-variable)                | Unused output variable                                    |\n| bugs        | [var-shadows-builtin](https://docs.styra.com/regal/rules/bugs/var-shadows-builtin)                      | Variable name shadows built-in                            |\n| bugs        | [zero-arity-function](https://docs.styra.com/regal/rules/bugs/zero-arity-function)                      | Avoid functions without args                              |\n| custom      | [forbidden-function-call](https://docs.styra.com/regal/rules/custom/forbidden-function-call)            | Forbidden function call                                   |\n| custom      | [missing-metadata](https://docs.styra.com/regal/rules/custom/missing-metadata)                          | Package or rule missing metadata                          |\n| custom      | [naming-convention](https://docs.styra.com/regal/rules/custom/naming-convention)                        | Naming convention violation                               |\n| custom      | [narrow-argument](https://docs.styra.com/regal/rules/custom/narrow-argument)                            | Function argument can be narrowed                         |\n| custom      | [one-liner-rule](https://docs.styra.com/regal/rules/custom/one-liner-rule)                              | Rule body could be made a one-liner                       |\n| custom      | [prefer-value-in-head](https://docs.styra.com/regal/rules/custom/prefer-value-in-head)                  | Prefer value in rule head                                 |\n| idiomatic   | [ambiguous-scope](https://docs.styra.com/regal/rules/idiomatic/ambiguous-scope)                         | Ambiguous metadata scope                                  |\n| idiomatic   | [boolean-assignment](https://docs.styra.com/regal/rules/idiomatic/boolean-assignment)                   | Prefer `if` over boolean assignment                       |\n| idiomatic   | [custom-has-key-construct](https://docs.styra.com/regal/rules/idiomatic/custom-has-key-construct)       | Custom function may be replaced by `in` and `object.keys` |\n| idiomatic   | [custom-in-construct](https://docs.styra.com/regal/rules/idiomatic/custom-in-construct)                 | Custom function may be replaced by `in` keyword           |\n| idiomatic   | [directory-package-mismatch](https://docs.styra.com/regal/rules/idiomatic/directory-package-mismatch)   | Directory structure should mirror package                 |\n| idiomatic   | [equals-pattern-matching](https://docs.styra.com/regal/rules/idiomatic/equals-pattern-matching)         | Prefer pattern matching in function arguments             |\n| idiomatic   | [in-wildcard-key](https://docs.styra.com/regal/rules/idiomatic/in-wildcard-key)                         | Unnecessary wildcard key                                  |\n| idiomatic   | [no-defined-entrypoint](https://docs.styra.com/regal/rules/idiomatic/no-defined-entrypoint)             | Missing entrypoint annotation                             |\n| idiomatic   | [non-raw-regex-pattern](https://docs.styra.com/regal/rules/idiomatic/non-raw-regex-pattern)             | Use raw strings for regex patterns                        |\n| idiomatic   | [prefer-set-or-object-rule](https://docs.styra.com/regal/rules/idiomatic/prefer-set-or-object-rule)     | Prefer set or object rule over comprehension              |\n| idiomatic   | [single-item-in](https://docs.styra.com/regal/rules/idiomatic/single-item-in)                           | Avoid `in` for single item collection                     |\n| idiomatic   | [use-contains](https://docs.styra.com/regal/rules/idiomatic/use-contains)                               | Use the `contains` keyword                                |\n| idiomatic   | [use-if](https://docs.styra.com/regal/rules/idiomatic/use-if)                                           | Use the `if` keyword                                      |\n| idiomatic   | [use-in-operator](https://docs.styra.com/regal/rules/idiomatic/use-in-operator)                         | Use in to check for membership                            |\n| idiomatic   | [use-object-keys](https://docs.styra.com/regal/rules/idiomatic/use-object-keys)                         | Prefer to use `object.keys`                               |\n| idiomatic   | [use-some-for-output-vars](https://docs.styra.com/regal/rules/idiomatic/use-some-for-output-vars)       | Use `some` to declare output variables                    |\n| idiomatic   | [use-strings-count](https://docs.styra.com/regal/rules/idiomatic/use-strings-count)                     | Use `strings.count` where possible                        |\n| imports     | [avoid-importing-input](https://docs.styra.com/regal/rules/imports/avoid-importing-input)               | Avoid importing input                                     |\n| imports     | [circular-import](https://docs.styra.com/regal/rules/imports/circular-import)                           | Circular import                                           |\n| imports     | [confusing-alias](https://docs.styra.com/regal/rules/imports/confusing-alias)                           | Confusing alias of existing import                        |\n| imports     | [ignored-import](https://docs.styra.com/regal/rules/imports/ignored-import)                             | Reference ignores import                                  |\n| imports     | [implicit-future-keywords](https://docs.styra.com/regal/rules/imports/implicit-future-keywords)         | Use explicit future keyword imports                       |\n| imports     | [import-after-rule](https://docs.styra.com/regal/rules/imports/import-after-rule)                       | Import declared after rule                                |\n| imports     | [import-shadows-builtin](https://docs.styra.com/regal/rules/imports/import-shadows-builtin)             | Import shadows built-in namespace                         |\n| imports     | [import-shadows-import](https://docs.styra.com/regal/rules/imports/import-shadows-import)               | Import shadows another import                             |\n| imports     | [pointless-import](https://docs.styra.com/regal/rules/imports/pointless-import)                         | Importing own package is pointless                        |\n| imports     | [prefer-package-imports](https://docs.styra.com/regal/rules/imports/prefer-package-imports)             | Prefer importing packages over rules                      |\n| imports     | [redundant-alias](https://docs.styra.com/regal/rules/imports/redundant-alias)                           | Redundant alias                                           |\n| imports     | [redundant-data-import](https://docs.styra.com/regal/rules/imports/redundant-data-import)               | Redundant import of data                                  |\n| imports     | [unresolved-import](https://docs.styra.com/regal/rules/imports/unresolved-import)                       | Unresolved import                                         |\n| imports     | [unresolved-reference](https://docs.styra.com/regal/rules/imports/unresolved-reference)                 | Unresolved Reference                                      |\n| imports     | [use-rego-v1](https://docs.styra.com/regal/rules/imports/use-rego-v1)                                   | Use `import rego.v1`                                      |\n| performance | [defer-assignment](https://docs.styra.com/regal/rules/performance/defer-assignment)                     | Assignment can be deferred                                |\n| performance | [non-loop-expression](https://docs.styra.com/regal/rules/performance/non-loop-expression)               | Non-loop expression                                       |\n| performance | [walk-no-path](https://docs.styra.com/regal/rules/performance/walk-no-path)                             | Call to `walk` can be optimized                           |\n| performance | [with-outside-test-context](https://docs.styra.com/regal/rules/performance/with-outside-test-context)   | `with` used outside test context                          |\n| style       | [avoid-get-and-list-prefix](https://docs.styra.com/regal/rules/style/avoid-get-and-list-prefix)         | Avoid `get_` and `list_` prefix for rules and functions   |\n| style       | [chained-rule-body](https://docs.styra.com/regal/rules/style/chained-rule-body)                         | Avoid chaining rule bodies                                |\n| style       | [comprehension-term-assignment](https://docs.styra.com/regal/rules/style/comprehension-term-assignment) | Assignment can be moved to comprehension term             |\n| style       | [default-over-else](https://docs.styra.com/regal/rules/style/default-over-else)                         | Prefer default assignment over fallback else              |\n| style       | [default-over-not](https://docs.styra.com/regal/rules/style/default-over-not)                           | Prefer default assignment over negated condition          |\n| style       | [detached-metadata](https://docs.styra.com/regal/rules/style/detached-metadata)                         | Detached metadata annotation                              |\n| style       | [double-negative](https://docs.styra.com/regal/rules/style/double-negative)                             | Avoid double negatives                                    |\n| style       | [external-reference](https://docs.styra.com/regal/rules/style/external-reference)                       | External reference in function                            |\n| style       | [file-length](https://docs.styra.com/regal/rules/style/file-length)                                     | Max file length exceeded                                  |\n| style       | [function-arg-return](https://docs.styra.com/regal/rules/style/function-arg-return)                     | Function argument used for return value                   |\n| style       | [line-length](https://docs.styra.com/regal/rules/style/line-length)                                     | Line too long                                             |\n| style       | [messy-rule](https://docs.styra.com/regal/rules/style/messy-rule)                                       | Messy incremental rule                                    |\n| style       | [mixed-iteration](https://docs.styra.com/regal/rules/style/mixed-iteration)                             | Mixed iteration style                                     |\n| style       | [no-whitespace-comment](https://docs.styra.com/regal/rules/style/no-whitespace-comment)                 | Comment should start with whitespace                      |\n| style       | [opa-fmt](https://docs.styra.com/regal/rules/style/opa-fmt)                                             | File should be formatted with `opa fmt`                   |\n| style       | [pointless-reassignment](https://docs.styra.com/regal/rules/style/pointless-reassignment)               | Pointless reassignment of variable                        |\n| style       | [prefer-snake-case](https://docs.styra.com/regal/rules/style/prefer-snake-case)                         | Prefer snake_case for names                               |\n| style       | [prefer-some-in-iteration](https://docs.styra.com/regal/rules/style/prefer-some-in-iteration)           | Prefer `some .. in` for iteration                         |\n| style       | [rule-length](https://docs.styra.com/regal/rules/style/rule-length)                                     | Max rule length exceeded                                  |\n| style       | [rule-name-repeats-package](https://docs.styra.com/regal/rules/style/rule-name-repeats-package)         | Rule name repeats package                                 |\n| style       | [todo-comment](https://docs.styra.com/regal/rules/style/todo-comment)                                   | Avoid TODO comments                                       |\n| style       | [trailing-default-rule](https://docs.styra.com/regal/rules/style/trailing-default-rule)                 | Default rule should be declared first                     |\n| style       | [unconditional-assignment](https://docs.styra.com/regal/rules/style/unconditional-assignment)           | Unconditional assignment in rule body                     |\n| style       | [unnecessary-some](https://docs.styra.com/regal/rules/style/unnecessary-some)                           | Unnecessary use of `some`                                 |\n| style       | [use-assignment-operator](https://docs.styra.com/regal/rules/style/use-assignment-operator)             | Prefer := over = for assignment                           |\n| style       | [yoda-condition](https://docs.styra.com/regal/rules/style/yoda-condition)                               | Yoda condition                                            |\n| testing     | [dubious-print-sprintf](https://docs.styra.com/regal/rules/testing/dubious-print-sprintf)               | Dubious use of print and sprintf                          |\n| testing     | [file-missing-test-suffix](https://docs.styra.com/regal/rules/testing/file-missing-test-suffix)         | Files containing tests should have a _test.rego suffix    |\n| testing     | [identically-named-tests](https://docs.styra.com/regal/rules/testing/identically-named-tests)           | Multiple tests with same name                             |\n| testing     | [metasyntactic-variable](https://docs.styra.com/regal/rules/testing/metasyntactic-variable)             | Metasyntactic variable name                               |\n| testing     | [print-or-trace-call](https://docs.styra.com/regal/rules/testing/print-or-trace-call)                   | Call to print or trace function                           |\n| testing     | [test-outside-test-package](https://docs.styra.com/regal/rules/testing/test-outside-test-package)       | Test outside of test package                              |\n| testing     | [todo-test](https://docs.styra.com/regal/rules/testing/todo-test)                                       | TODO test encountered                                     |\n\n\u003c!-- RULES_TABLE_END --\u003e\n\nRules in all categories except for those in `custom` are **enabled** by default. Some rules however — like\n`use-contains` and `use-if` — are conditionally enabled only when a version of OPA/Rego before 1.0 is targeted. See the\nconfiguration options below if you want to use Regal to lint \"legacy\" policies.\n\n**Aggregate Rules**\n\nMost Regal rules will use data only from a single file at a time, with no consideration for other files. A few rules\nhowever require data from multiple files, and will therefore collect, or aggregate, data from all files provided for\nlinting. These rules are called *aggregate rules*, and will only be run when there is more than one file to lint, such\nas when linting a directory or a whole policy repository. One example of such a rule is the `prefer-package-imports`\nrule, which will aggregate package names and imports from all provided policies in order to determine if any imports\nare pointing to rules or functions rather than packages. You normally won't need to care about this distinction other\nthan being aware of the fact that some linter rules won't be run when linting a single file.\n\nIf you'd like to see more rules, please [open an issue](https://github.com/StyraInc/regal/issues) for your feature\nrequest, or better yet, submit a PR! See the [custom rules](/docs/custom-rules.md) page for more information on how to\ndevelop your own rules, for yourself or for inclusion in Regal.\n\n### Custom Rules\n\nThe `custom` category is a special one, as the rules in this category allow you to enforce rules that are specific to\nyour project, team or organization. This typically includes things like naming conventions, where you might want to\nensure that, for example, all package names adhere to an organizational standard, like having a prefix matching the\norganization name.\n\nSince these rules require configuration provided by the user, or are more opinionated than other rules, they are\ndisabled by default. In order to enable them, see the configuration options available for each rule for how to configure\nthem according to your requirements.\n\nFor more advanced requirements, see the guide on writing [custom rules](/docs/custom-rules.md) in Rego.\n\n## Configuration\n\nA custom configuration file may be used to override the [default configuration](https://github.com/StyraInc/regal/blob/main/bundle/regal/config/provided/data.yaml)\noptions provided by Regal. The most common use case for this is to change the severity level of a rule. These three\nlevels are available:\n\n- `ignore`  — disable the rule entirely\n- `warning` — report the violation without changing the exit code of the lint command\n- `error`   — report the violation and have the lint command exit with a non-zero exit code (default)\n\nAdditionally, some rules may have configuration options of their own. See the documentation page for a rule to learn\nmore about it.\n\n**.regal/config.yaml** or **.regal.yaml**\n```yaml\nrules:\n  style:\n    todo-comment:\n      # don't report on todo comments\n      level: ignore\n    line-length:\n      # custom rule configuration\n      max-line-length: 100\n      # warn on too long lines, but don't fail\n      level: warning\n    opa-fmt:\n      # not needed as error is the default, but\n      # being explicit won't hurt\n      level: error\n      # files can be ignored for any individual rule\n      # in this example, test files are ignored\n      ignore:\n        files:\n          - \"*_test.rego\"\n  custom:\n    # custom rule configuration\n    naming-convention:\n      level: error\n      conventions:\n        # ensure all package names start with \"acmecorp\" or \"system\"\n        - pattern: '^acmecorp\\.[a-z_\\.]+$|^system\\.[a-z_\\.]+$'\n          targets:\n            - package\n\ncapabilities:\n  from:\n    # optionally configure Regal to target a specific version of OPA\n    # this will disable rules that has dependencies to e.g. built-in\n    # functions or features not supported by the given version\n    #\n    # if not provided, Regal will use the capabilities of the latest\n    # version of OPA available at the time of the Regal release\n    engine: opa\n    version: v0.58.0\n\nignore:\n  # files can be excluded from all lint rules according to glob-patterns\n  files:\n    - file1.rego\n    - \"*_tmp.rego\"\n\nproject:\n  roots:\n    # declares the 'main' and 'lib/jwt' directories as project roots\n    - main\n    - lib/jwt\n    # may also be provided as an object with additional options\n    - path: lib/legacy\n      rego-version: 0\n```\n\nRegal will automatically search for a configuration file (`.regal/config.yaml`\nor `.regal.yaml`) in the current directory, and if not found, traverse the\nparent directories either until either one is found, or the top of the directory\nhierarchy is reached. If no configuration file is found, and no file is found at\n`~/.config/regal/config.yaml` either, Regal will use the default configuration.\n\nA custom configuration may be also be provided using the `--config-file`/`-c`\noption for `regal lint`, which when provided will be used to override the\ndefault configuration.\n\n### User-level Configuration\n\nGenerally, users will want to commit their Regal configuration file to the repo\ncontaining their Rego source code. This allows configurations to be shared\namong team members and makes the configuration options available to Regal when\nrunning as a [CI linter](https://docs.styra.com/regal/cicd) too.\n\nSometimes however it can be handy to have some user defaults when a project\nconfiguration file is not found, hasn't been created yet or is not applicable.\n\nIn such cases Regal will check for a configuration file at\n`~/.config/regal/config.yaml` instead.\n\n## Ignoring Rules\n\nIf one of Regal's rules doesn't align with your team's preferences, don't worry! Regal is not meant to be the law,\nand some rules may not make sense for your project, or parts of it.\nRegal provides several different methods to ignore rules with varying precedence.\nThe available methods are (ranked highest to lowest precedence):\n\n- [Inline Ignore Directives](#inline-ignore-directives) cannot be overridden by any other method.\n- Enabling or Disabling Rules with CLI flags.\n  - Enabling or Disabling Rules with `--enable` and `--disable` CLI flags.\n  - Enabling or Disabling Rules with `--enable-category` and `--disable-category` CLI flags.\n  - Enabling or Disabling All Rules with `--enable-all` and `--disable-all` CLI flags.\n  - See [Ignoring Rules via CLI Flags](#ignoring-rules-via-cli-flags) for more details.\n- [Ignoring a Rule In Config](#ignoring-a-rule-in-config)\n- [Ignoring a Category In Config](#ignoring-a-category-in-config)\n- [Ignoring All Rules In Config](#ignoring-all-rules-in-config)\n\nIn summary, the CLI flags will override any configuration provided in the file, and inline ignore directives for a\nspecific line will override any other method.\n\nIt's also possible to ignore messages on a per-file basis. The available methods are (ranked High to Lowest precedence):\n\n- Using the `--ignore-files` CLI flag.\n  See [Ignoring Rules via CLI Flags](#ignoring-rules-via-cli-flags).\n- [Ignoring Files Globally](#ignoring-files-globally) or\n  [Ignoring a Rule in Some Files](#ignoring-a-rule-in-some-files).\n\n### Ignoring a Rule in Config\n\nIf you want to ignore a rule, set its level to `ignore` in the configuration file:\n\n```yaml\nrules:\n  style:\n    prefer-snake-case:\n      # At example.com, we use camel case to comply with our naming conventions\n      level: ignore\n```\n\n### Ignoring a Category in Config\n\nIf you want to ignore a category of rules, set its default level to `ignore` in the configuration file:\n\n```yaml\nrules:\n  style:\n    default:\n      level: ignore\n```\n\n### Ignoring All Rules in Config\n\nIf you want to ignore all rules, set the default level to `ignore` in the configuration file:\n\n```yaml\nrules:\n  default:\n    level: ignore\n  # then you can re-enable specific rules or categories\n  testing:\n    default:\n      level: error\n  style:\n    opa-fmt:\n      level: error\n```\n\n**Tip**: providing a comment on ignored rules is a good way to communicate why the decision was made.\n\n### Ignoring a Rule in Some Files\n\nYou can use the `ignore` attribute inside any rule configuration to provide a list of files, or patterns, that should\nbe ignored for that rule:\n\n```yaml\nrules:\n  style:\n    line-length:\n      level: error\n      ignore:\n        files:\n          # ignore line length in test files to accommodate messy test data\n          - \"*_test.rego\"\n          # specific file used only for testing\n          - \"scratch.rego\"\n```\n\n### Ignoring Files Globally\n\n**Note**: Ignoring files will disable most language server features\nfor those files. Only formatting will remain available.\nIgnored files won't be used for completions, linting, or definitions\nin other files.\n\nIf you want to ignore certain files for all rules, you can use the global ignore attribute in your configuration file:\n\n```yaml\nignore:\n  files:\n    - file1.rego\n    - \"*_tmp.rego\"\n```\n\n### Inline Ignore Directives\n\nIf you'd like to ignore a specific violation in a file, you can add an ignore directive above the line in question, or\nalternatively on the same line to the right of the expression:\n\n```rego\npackage policy\n\n# regal ignore:prefer-snake-case\ncamelCase := \"yes\"\n\nlist_users contains user if { # regal ignore:avoid-get-and-list-prefix\n    some user in data.db.users\n    # ...\n}\n```\n\nThe format of an ignore directive is `regal ignore:\u003crule-name\u003e,\u003crule-name\u003e...`, where `\u003crule-name\u003e` is the name of the\nrule to ignore. Multiple rules may be added to the same ignore directive, separated by commas.\n\nNote that at this point in time, Regal only considers the same line or the line following the ignore directive, i.e. it\ndoes not apply to entire blocks of code (like rules, functions or even packages). See [configuration](#configuration)\nif you want to ignore certain rules altogether.\n\n### Ignoring Rules via CLI Flags\n\nFor development and testing, rules or classes of rules may quickly be enabled or disabled using the relevant CLI flags\nfor the `regal lint` command:\n\n- `--disable-all` disables **all** rules\n- `--disable-category` disables all rules in a category, overriding `--enable-all` (may be repeated)\n- `--disable` disables a specific rule, overriding `--enable-all` and `--enable-category` (may be repeated)\n- `--enable-all` enables **all** rules\n- `--enable-category` enables all rules in a category, overriding `--disable-all` (may be repeated)\n- `--enable` enables a specific rule, overriding `--disable-all` and `--disable-category` (may be repeated)\n- `--ignore-files` ignores files using glob patterns, overriding `ignore` in the config file (may be repeated)\n\n**Note:** all CLI flags override configuration provided in file.\n\n## Configuring Rego Version\n\nFrom OPA 1.0 and onwards, it is no longer necessary to include `import rego.v1` in your policies in order to use\nkeywords like `if` and `contains`. Since Regal works with with both 1.0+ policies and older versions of Rego, the linter\nwill first try to parse a policy as 1.0 and if that fails, parse using \"v0\" rules. This process isn't 100% foolproof,\nas some policies are valid in both versions. Additionally, parsing the same file multiple times adds some overhead that\ncan be skipped if the version is known beforehand. To help Regal determine (and enforce) the version of your policies,\nthe `rego-version` attribute can be set in the `project` configuration:\n\n```yaml\nproject:\n  # Rego version 1.0, set to 0 for pre-1.0 policies\n  rego-version: 1\n```\n\nIt is also possible to set the Rego version for individual project roots (see below for more information):\n\n```yaml\nproject:\n  roots:\n    - path: lib/legacy\n      rego-version: 0\n    - path: main\n      rego-version: 1\n```\n\nAdditionally, Regal will scan the project for any `.manifest` files, and user any `rego_version` found in the manifest\nfor all policies under that directory.\n\nNote: the `rego-version` attribute in the configuration file has precedence over `rego_version` found in manifest files.\n\n## Project Roots\n\nWhile many projects consider the project's root directory (in editors often referred to as **workspace**) their\n\"main\" directory for policies, some projects may contain code from other languages, policy \"subprojects\", or multiple\n[bundles](https://www.openpolicyagent.org/docs/latest/management-bundles/). While most of Regal's features works\nindependently of this — linting, for example, doesn't consider where in a workspace policies are located as long as\nthose locations aren't [ignored](#ignoring-files-globally) — some features, like automatically\n[fixing](https://docs.styra.com/regal/fixing) violations, benefit from knowing when a project contains multiple roots.\n\nTo provide an example, consider the\n[directory-package-mismatch](https://docs.styra.com/regal/rules/idiomatic/directory-package-mismatch) rule, which states\nthat a file declaring a `package` path like `policy.permissions.users` should also be located in a directory structure\nthat mirrors that package, i.e. `policy/permissions/users`. When a violation against this rule is reported, the\n`regal fix` command, or its equivalent [Code Action](#regal-language-server) in editors, may when invoked remediate the\nissue by moving the file to the correct location. But where should the `policy/permissions/users` directory *itself*\nreside?\n\nNormally, the answer to that question would be the **project**, or **workspace** root. But if the file was found\nin a subdirectory containing a **bundle**, the directory naturally belongs under that *bundle's root* instead. The\n`roots` configuration option under the top-level `project` object allows you to tell Regal where these roots are,\nand have features like the `directory-package-mismatch` fixer work as you'd expect.\n\n```yaml\nproject:\n  roots:\n    - bundle1\n    - bundle2\n```\n\nThe configuration file is not the only way Regal may determine project roots. Other ways include:\n\n- A directory containing a `.manifest` file will automatically be registered as a root\n- A directory containing a `.regal` directory will be registered as a root (this is normally the project root)\n\nIf a feature that depends on project roots fails to identify any, it will either fail or fall back on the directory\nin which the command was run.\n\n## Capabilities\n\nBy default, Regal will lint your policies using the\n[capabilities](https://www.openpolicyagent.org/docs/latest/deployments/#capabilities) of the latest version of OPA\nknown to Regal (i.e. the latest version of OPA at the time Regal was released). Sometimes you might want to tell Regal\nthat some rules aren't applicable to your project (yet!). As an example, if you're running OPA v0.46.0, you likely won't\nbe helped by the [custom-has-key](https://docs.styra.com/regal/rules/idiomatic/custom-has-key-construct) rule, as it\nsuggests using the `object.keys` built-in function introduced in OPA v0.47.0. The opposite could also be true —\nsometimes new versions of OPA will invalidate rules that applied to older versions. An example of this is the upcoming\nintroduction of `import rego.v1`, which will make\n[implicit-future-keywords](https://docs.styra.com/regal/rules/imports/implicit-future-keywords) obsolete, as importing\n`rego.v1` automatically imports all \"future\" functions.\n\nCapabilities help you tell Regal which features to take into account, and rules with dependencies to capabilities\nnot available or not applicable in the given version will be skipped.\n\nIf you'd like to target a specific version of OPA, you can include a `capabilities` section in your configuration,\nproviding either a specific `version` of an `engine` (currently only `opa` supported):\n\n```yaml\ncapabilities:\n  from:\n    engine: opa\n    version: v0.58.0\n```\n\nYou can also choose to import capabilities from a file:\n\n```yaml\ncapabilities:\n  from:\n    file: build/capabilities.json\n```\n\nYou can use `plus` and `minus` to add or remove built-in functions from the given set of capabilities:\n\n```yaml\ncapabilities:\n  from:\n    engine: opa\n    version: v0.58.0\n  minus:\n    builtins:\n      # exclude rules that depend on the http.send built-in function\n      - name: http.send\n  plus:\n    builtins:\n      # make Regal aware of a custom \"ldap.query\" function\n      - name: ldap.query\n        type: function\n        decl:\n          args:\n            - type: string\n        result:\n          type: object\n```\n\n### Loading Capabilities from URLs\n\nStarting with Regal version v0.26.0, Regal can load capabilities from URLs with the `http`, or `https` schemes using\nthe `capabilities.from.url` config key. For example, to load capabilities from `https://example.org/capabilities.json`,\nthis configuration could be used:\n\n```yaml\ncapabilities:\n  from:\n    url: https://example.org/capabilities.json\n```\n\n### Supported Engines\n\nRegal includes capabilities files for the following engines:\n\n| Engine | Website | Description |\n|--------|---------|-------------|\n| `opa`  | [OPA website](https://www.openpolicyagent.org/) | Open Policy Agent |\n| `eopa` | [Enterprise OPA website](https://www.styra.com/enterprise-opa/) | Styra Enterprise OPA |\n\n## Exit Codes\n\nExit codes are used to indicate the result of the `lint` command. The `--fail-level` provided for `regal lint` may be\nused to change the exit code behavior, and allows a value of either `warning` or `error` (default).\n\nIf `--fail-level error` is supplied, exit code will be zero even if warnings are present:\n\n- `0`: no errors were found\n- `0`: one or more warnings were found\n- `3`: one or more errors were found\n\nThis is the default behavior.\n\nIf `--fail-level warning` is supplied, warnings will result in a non-zero exit code:\n\n- `0`: no errors or warnings were found\n- `2`: one or more warnings were found\n- `3`: one or more errors were found\n\n## Output Formats\n\nThe `regal lint` command allows specifying the output format by using the `--format` flag. The available output formats\nare:\n\n- `pretty` (default) - Human-readable table-like output where each violation is printed with a detailed explanation\n- `compact` - Human-readable output where each violation is printed on a single line\n- `json` - JSON output, suitable for programmatic consumption\n- `github` - GitHub [workflow command](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions)\n  output, ideal for use in GitHub Actions. Annotates PRs and creates a\n  [job summary](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary)\n  from the linter report\n- `sarif` - [SARIF](https://sarifweb.azurewebsites.net/) JSON output, for consumption by tools processing code analysis\n  reports\n- `junit` - JUnit XML output, e.g. for CI servers like GitLab that show these results in a merge request.\n\n## OPA Check and Strict Mode\n\nOPA itself provides a \"linter\" of sorts, via the `opa check` command and its `--strict` flag. This checks the provided\nRego files not only for syntax errors, but also for OPA\n[strict mode](https://www.openpolicyagent.org/docs/latest/policy-language/#strict-mode) violations. Most of the strict\nmode checks from before OPA 1.0 have now been made default checks in OPA, and only two additional checks are currently\nprovided by the `--strict` flag. Those are both important checks not covered by Regal though, so our recommendation is\nto run `opa check --strict` against your policies before linting with Regal.\n\n## Regal Language Server\n\nIn order to support linting directly in editors and IDE's, Regal implements parts of the\n[Language Server Protocol](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/)\n(LSP). With Regal installed and available on your `$PATH`, editors like VS Code (using the\n[OPA extension](https://github.com/open-policy-agent/vscode-opa)) and Zed (using the\n[zed-rego](https://github.com/StyraInc/zed-rego) extension) can leverage Regal for diagnostics, i.e. linting,\nand have the results displayed directly in your editor as you work on your Rego policies. The Regal LSP implementation\ndoesn't stop at linting though — it'll also provide features like tooltips on hover, go to definition, and document\nsymbols helping you easily navigate the Rego code in your workspace.\n\nThe Regal language server currently supports the following LSP features:\n\n- [x] [Diagnostics](https://docs.styra.com/regal/language-server#diagnostics) (linting)\n- [x] [Hover](https://docs.styra.com/regal/language-server#hover)\n      (for inline docs on built-in functions)\n- [x] [Go to definition](https://docs.styra.com/regal/language-server#go-to-definition)\n      (ctrl/cmd + click on a reference to go to definition)\n- [x] [Folding ranges](https://docs.styra.com/regal/language-server#folding-ranges)\n      (expand/collapse blocks, imports, comments)\n- [x] [Document and workspace symbols](https://docs.styra.com/regal/language-server#document-and-workspace-symbols)\n      (navigate to rules, functions, packages)\n- [x] [Inlay hints](https://docs.styra.com/regal/language-server#inlay-hints)\n      (show names of built-in function arguments next to their values)\n- [x] [Formatting](https://docs.styra.com/regal/language-server#formatting)\n- [x] [Code completions](https://docs.styra.com/regal/language-server#code-completions)\n- [x] [Code actions](https://docs.styra.com/regal/language-server#code-actions)\n      (quick fixes for linting issues)\n  - [x] [opa-fmt](https://docs.styra.com/regal/rules/style/opa-fmt)\n  - [x] [use-rego-v1](https://docs.styra.com/regal/rules/imports/use-rego-v1)\n  - [x] [use-assignment-operator](https://docs.styra.com/regal/rules/style/use-assignment-operator)\n  - [x] [no-whitespace-comment](https://docs.styra.com/regal/rules/style/no-whitespace-comment)\n  - [x] [directory-package-mismatch](https://docs.styra.com/regal/rules/idiomatic/directory-package-mismatch)\n- [x] [Code lenses](https://docs.styra.com/regal/language-server#code-lenses-evaluation)\n      (click to evaluate any package or rule directly in the editor)\n\nSee the\n[documentation page for the language server](https://github.com/StyraInc/regal/blob/main/docs/language-server.md)\nfor an extensive overview of all features, and their meaning.\n\nSee the [Editor Support](/docs/editor-support.md) page for information about Regal support in different editors.\n\n## Regal and OPA 1.0+\n\nStarting from version v0.30.0, Regal supports working with both\n[OPA 1.0+]((https://blog.openpolicyagent.org/announcing-opa-1-0-a-new-standard-for-policy-as-code-a6d8427ee828))\npolicies and Rego from earlier versions of OPA. While everything should work without additional configuration,\nwe recommend checking out our documentation on using Regal with [OPA 1.0](https://docs.styra.com/regal/opa-one-dot-zero)\nand later for the best possible experience managing projects of any given Rego version, or even a mix of them.\n\n## Resources\n\n### Documentation\n\n- [Custom Rules](/docs/custom-rules.md) describes how to develop your own linter rules\n- [Architecture](/docs/architecture.md) provides a high-level technical overview of how Regal works\n- [Contributing](/docs/CONTRIBUTING.md) contains information about how to hack on Regal itself\n- [Go Integration](/docs/integration.md) describes how to integrate Regal in your Go application\n- [Rego Style Guide](/docs/rego-style-guide.md) contains notes on implementing the\n  [Rego Style Guide](https://github.com/StyraInc/rego-style-guide) rules\n- [Pre-Commit Hooks](/docs/pre-commit-hooks.md) describes how to use Regal in pre-commit hooks\n- [Editor Support](/docs/editor-support.md) contains information about editor support for Regal\n\n### Talks\n\n- [OPA Maintainer Track, featuring Regal](https://www.youtube.com/watch?v=XtA-NKoJDaI), KubeCon London, 2025\n- [Regal the Rego Linter](https://www.youtube.com/watch?v=Xx8npd2TQJ0\u0026t=2567s), CNCF London meetup, June 2023\n[![Regal the Rego Linter](/docs/assets/regal_cncf_london.png)](https://www.youtube.com/watch?v=Xx8npd2TQJ0\u0026t=2567s)\n\n### Blogs and Articles\n\n- [Guarding the Guardrails - Introducing Regal the Rego Linter](https://www.styra.com/blog/guarding-the-guardrails-introducing-regal-the-rego-linter/)\n  by Anders Eknert ([@anderseknert](https://github.com/anderseknert))\n- [Scaling Open Source Community by Getting Closer to Users](https://thenewstack.io/scaling-open-source-community-by-getting-closer-to-users/)\n  by Charlie Egan ([@charlieegan3](https://github.com/charlieegan3))\n- [Renovating Rego](https://www.styra.com/blog/renovating-rego/) by Anders Eknert ([@anderseknert](https://github.com/anderseknert))\n- [Linting Rego with... Rego!](https://www.styra.com/blog/linting-rego-with-rego/) by Anders Eknert ([@anderseknert](https://github.com/anderseknert))\n- [Regal: Rego(OPA)用リンタの導入手順](https://zenn.dev/erueru_tech/articles/6cfb886d92858a) by Jun Fujita ([@erueru-tech](https://github.com/erueru-tech))\n- [Regal を使って Rego を Lint する](https://tech.dentsusoken.com/entry/2024/12/05/Regal_%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6_Rego_%E3%82%92_Lint_%E3%81%99%E3%82%8B)\n  by Shibata Takao ([@shibata.takao](https://shodo.ink/@shibata.takao/))\n\n## Status\n\nRegal is currently in beta. End-users should not expect any drastic changes, but any API may change without notice.\nIf you want to embed Regal in another project or product, please reach out!\n\n## Roadmap\n\nThe Regal project roadmap is subject to change, but these are some of the features we're planning to work on\nin the near future:\n\n### Linter\n\n- [x] Full support for both OPA 1.0 policies and older versions of Rego\n- [ ] Allow remediation of more `style` category rules using the `regal fix` command\n- [ ] Add [unused-rule](https://github.com/StyraInc/regal/issues/358) linter\n- [x] Add [unused-output-variable](https://github.com/StyraInc/regal/issues/60) linter\n\n### Language Server\n\n- [ ] Make \"Check on save\" unnecessary by allowing diagnostics to include\n      [compilation errors](https://github.com/StyraInc/regal/issues/745)\n- [x] Add Code Lens to \"Evaluate\" any rule or package (VS Code only, initially)\n- [ ] Implement [Signature Help](https://github.com/StyraInc/regal/issues/695) feature\n\nThe roadmap is updated when all the current items have been completed.\n\nIf there's something you'd like to have added to the roadmap, either open an issue, or reach out in the community Slack!\n\n## Community\n\nFor questions, discussions and announcements related to Styra products, services and open source projects, please join\nthe Styra community on [Slack](https://inviter.co/styra)!\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstyrainc%2Fregal","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstyrainc%2Fregal","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstyrainc%2Fregal/lists"}