forcedotcom / forcedotcom/code-analyzer
[Feature Request] File based regex rules
- 主要言語
- TypeScript
- スター
- 240
- フォーク
- 52
- 平均マージ
- 1日 23時間
- マージ済み PR(30日)
- 5
説明
### Product Area
The "code-analyzer" CLI
### Your Need or Problem
Allow for regex rules to be placed into their own files and referenced from `code-analyzer.yml` so that they can be more easily shared between projects instead of merging them into existing files.
### Your Desired Solution
Lets say we had the rule:
```yaml
name: Salesforce Code Analyzer Configuration
version: 1.0.0
rulesets: []
engines:
regex:
custom_rules:
ProhibitSuppressWarnings:
regex: /@SuppressWarnings\([^)]*\)|\/\/\s*NOPMD/gi
file_extensions: ['.apex', '.cls', '.trigger']
description:
'Prohibits the use of @SuppressWarnings annotations and
NOPMD comments in Apex code. Suppressions hide code quality
issues; prefer fixing the underlying problems or improving
rules instead.'
violation_message:
'Suppression of warnings is not allowed. Fix the underlying
issue or improve the rule instead of suppressing violations.'
severity: 'High'
tags: ['CodeStyle', 'Recommended']
```
I would like to take the details of that rule and put them in a different .yaml file, then refer to that .yaml file from code-analyzer.yml
### Alternatives Considered
Keep adding rules to code-analyzer.yml like today, using a pre-processor/script ahead of every run, etc
### Additional Context (Screenshots, Files, etc)
_No response_
### Workaround
_No response_
### Urgency
Low
コントリビューションガイド
調査の方向性
code-analyzer.yml を読み込む CLI エントリポイントから開始し、regex custom_rules がどのようにパースされるかを追跡します。外部の YAML ルールファイルをどのように参照して共有できるかを確認し、そのうえで、代表的な CLI 実行において既存のインラインルールがファイルベースのルールと併用して引き続き動作することを検証します。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- typescript
- 領域
- cli, tooling
- issue の種類
- 機能追加
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100