| Concern | Tool | Version Strategy |
|---|---|---|
| Linter | rubocop | Latest in container |
| Linter | rubocop-rails | Latest in container |
| Linter | rubocop-rspec | Latest in container |
| Linter | rubocop-performance | Latest in container |
| Formatter | rubocop | Latest in container |
| Security | brakeman | Latest in container |
| Security | bundler-audit | Latest in container |
| Tests | rspec | Latest in container |
| Code Smells | reek | Latest in container |
| Type Check | sorbet | Latest in container |
Config file: .rubocop.yml at repository root.
Recommended .rubocop.yml:
require:
- rubocop-rails
- rubocop-rspec
- rubocop-performance
AllCops:
TargetRubyVersion: 3.1
NewCops: enable
Exclude:
- "db/schema.rb"
- "bin/**/*"
- "vendor/**/*"
- "node_modules/**/*"
Style/Documentation:
Enabled: false
Metrics/BlockLength:
Exclude:
- "spec/**/*"
- "config/routes.rb"
Layout/LineLength:
Max: 120rubocop handles both linting and formatting. Do not use standardrb or prettier-ruby separately.
Config file: .reek.yml at repository root.
Recommended .reek.yml:
exclude_paths:
- vendor
- db/schema.rb
- bin
detectors:
IrresponsibleModule:
enabled: false
UncommunicativeVariableName:
accept:
- e
- i
- k
- vConfig file: .rspec at repository root.
Recommended .rspec:
--require spec_helper
--format documentation
--color
Config file: sorbet/config at repository root.
Recommended sorbet/config:
--dir
.
--ignore=vendor/
--ignore=db/
--ignore=bin/
Sorbet uses typed signatures (# typed: strict, # typed: true, etc.) at the top of each file. Start with # typed: false and incrementally adopt.
No config file required. Brakeman scans Rails applications for common security vulnerabilities. It only applies to Rails projects (detected by config/application.rb).
No config file required. Scans Gemfile.lock for known vulnerable gem versions. Run bundler-audit update periodically to refresh the advisory database.
| Target | Command | Description |
|---|---|---|
_lint |
rubocop . |
Lint all Ruby files |
_lint |
reek . |
Detect code smells |
_format |
rubocop --check --fail-level error . |
Check formatting (no changes) |
_format (fix) |
rubocop -a . |
Apply safe auto-corrections |
_security |
brakeman -q |
Rails security scanning (Rails only) |
_security |
bundler-audit check |
Dependency vulnerability scanning |
_test |
rspec |
Run test suite |
See DEVELOPMENT.md for the full Makefile contract and two-layer delegation pattern.
These run on every commit via pre-commit:
repos:
- repo: https://github.com/rubocop/rubocop
rev: "" # container manages version
hooks:
- id: rubocopThese run via make security and make test in CI pipelines. They are not configured as pre-commit hooks due to execution time:
brakeman -q-- Rails security scanningbundler-audit check-- dependency vulnerability scanningrspec-- full test suitereek .-- code smell detection (when project is large)sorbet-- type checking (when project adopts typed signatures)
- rubocop is the single tool for both linting and formatting. Do not use standardrb or prettier-ruby.
rubocop-rails,rubocop-rspec, andrubocop-performanceare rubocop extensions loaded viarequire:in.rubocop.yml. They are not standalone tools.brakemanonly runs for Rails applications. It is skipped ifconfig/application.rbis not present.bundler-auditonly runs ifGemfile.lockexists. It checks for known vulnerabilities in declared gem dependencies.reekruns as part ofmake lint. It detects code smells (feature envy, too-many-instance-variables, etc.).sorbetis optional. Projects can incrementally adopt it by adding# typed:sigils to files.- All tools are pre-installed in the dev-toolchain container. Do not install them on the host.
- Rails rspec in CI: The dev-toolchain container handles static analysis (rubocop, reek, brakeman, bundler-audit) but Rails integration tests typically need a database service (Postgres, MySQL). In CI, run a separate rspec job with the project's own
rubyimage, Bundler, and a database service. The DevRailmake _testtarget handles rspec for simple cases; use a dedicated CI job when your tests require external services. - For cross-cutting practices (DRY, idempotency, error handling, testing, naming) and git workflow (branching, code review, conventional commits), see Coding Practices and Git Workflow.