Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Proposal for handling additional file inclusions/exclusions

Abierto
#369 0 comentarios 1 reacción 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
rails, ruby
Área
backend

Línea de trabajo

Start by reading the existing model discovery and related-file expansion code, plus the configuration and tests for the exclusion options discussed in PRs #267 and #300. The issue proposes two alternative designs but does not choose one or identify files to change. Done means a chosen design is implemented and tested for model filtering and related-file exclusions.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I have been thinking through this and the other issues. In the end, it would be great to move away from option flags towards an explicit structure for controlling what does and does not get annotated. Do let me know what you think. Note: I used AI to create the proposals. (Moved this from #300)

How I think the ideal pipeline could be:

The Pipeline

1. Model discovery    →  scan model_dir globs, find candidate .rb files
2. Model filter       →  whitelist OR exclusion (mutually exclusive) — PRs #267 and #300
                         ↓  surviving models
3. Related file       →  per model, expand to related files via patterns
   expansion             (additional_file_patterns, test/fixture/factory patterns, etc.)
                         ↓  combined set: models + related files
4. Related file       →  additional exclusions for step 3, for example if you want to exclude annotating tests for a specific model
   filtering
                         ↓  final set to annotate

These are two options for handling exclusion

Option A — Unified Exclusion

A single exclude_patterns option operates on the combined set (models + related files) after expansion. (This would happen at step 4)

# .annotaterb.yml

exclude_patterns:
  - "**/*.spec.rb"       # prevents spec files from being treated as models
  - "spec/billing/**/*"  # prevents billing-related specs from being annotated

How it works:

  1. Model discovery finds all candidate files
  2. Model-level whitelist or exclusion is applied (PRs #267/#300)
  3. Related files are expanded per model
  4. exclude_patterns is applied to the combined set — any file matching a pattern is dropped

Pros:

  • Single concept and single config key — easy to explain and document
  • Consistent: the same mechanism handles both model-level and related-file-level exclusion
  • Familiar — similar to .gitignore semantics

Cons:

  • Loses the distinction between "don't treat this as a model" and "don't annotate this related file" — both collapse into "don't touch this file"
  • A pattern intended to exclude related files could unintentionally also exclude model files if written broadly
  • Less explicit about which layer is being targeted

Option B — Separate Exclusion Options

Two distinct options target different layers of the pipeline explicitly.

# .annotaterb.yml

# Affects model discovery only — prevents files from being loaded as models
exclude_model_patterns:
  - "**/*.spec.rb"

# Affects related file annotation only — models are still processed, but
# matching related files are skipped
exclude_related_file_patterns:
  - "spec/billing/**/*"

How it works:

  1. Model discovery finds all candidate files
  2. exclude_model_patterns is applied — matching files are dropped before any model loading
  3. Related files are expanded per surviving model
  4. exclude_related_file_patterns is applied to the related file set only

Pros:

  • Explicit — the user knows exactly which layer they are targeting
  • exclude_model_patterns cleanly handles PR #267 (.spec.rb files in model directories)
  • exclude_related_file_patterns cleanly complements the existing exclude_* boolean flags with pattern-based control
  • No risk of a related-file pattern accidentally excluding a model file

Cons:

  • Two options to learn and document instead of one
  • User must understand the distinction between model discovery and related file annotation to use correctly
  • Slightly more config verbosity
Lenguaje dominante
Ruby
Estrellas
624
Forks
95
Merge medio
1 d 21 h
PR fusionados (30 d)
10

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de drwl/annotaterb

Todos los issues de drwl/annotaterb

Issues similares

Más issues de Ruby

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.