Single source of truth for duplicated scripts (merge-config x5, merge-help-csv x5, cleanup-legacy x3, scanners x2)
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 49/100
- Tipo di issue
- Refactoring
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- javascript, node.js, python
- Ambito
- tooling
Direzione di ricerca
Start by reading test_canon_sync.py and comparing the duplicated scripts named in the issue, especially the scanner copies that have already drifted. Decide whether to add the canonical-copy table there or create tools/sync-vendored.mjs with a CI drift check; the issue leaves that direction open. Done means one canonical source is defined for each listed script and drift is detected or copies are generated consistently.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Describe your idea
Keep one canonical copy of each duplicated script, and generate or verify the others.
Why is this needed?
merge-config.py and merge-help-csv.py each exist as 5 byte-identical copies (bmb-setup, the two module-builder templates, two samples), and cleanup-legacy.py as 3. The scanners already drifted: scan-path-standards.py differs by 51 diff lines between builders (#115), and a self-detection fix landed only in the agent-builder scan-scripts.py. Every fix has to be applied 3–5 times, and some get missed.
How should it work?
Either:
- a
tools/sync-vendored.mjsthat copies from a canonical location at release time (and a CI check that fails on drift), or - extend
test_canon_sync.pyinto a table of(canonical, [copies])covering all of the above.
The first is less error-prone; the second needs no build step.
PR
Happy to help implement this if the direction is agreed.
- Lingua principale
- Python
- Stelle
- 220
- Fork
- 54
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di bmad-code-org/bmad-builder
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
bmad-code-org/bmad-builder#157 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
bmad-code-org/bmad-builder#153 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
bmad-code-org/bmad-builder#151 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 77/100
bmad-code-org/bmad-builder#127 ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
bmad-code-org/bmad-builder#123 ·
Tutte le issue di bmad-code-org/bmad-builder
Issue simili
-
namespace
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 68/100
EclipseFdn/open-vsx.org#15604 ·
I maintainer di solito rispondono entro 1 giorno
-
app: scripts severity: low status: backlog type: bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
netbox-community/netbox-scripts#164 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 85/100
I maintainer di solito rispondono entro 5 giorni
-
Public function to read participants.tsvForse già presa @bruAristimunha l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 1-3 ore Idoneità per principianti 85/100
huggingface/tau#799 ·
I maintainer di solito rispondono entro 2 giorni