chore(tooling): adoptar rustfmt con gate de CI de formato (baseline no fmt-clean)
メンテナーはふだん 1 日以内に返信
@SrStamm がすでに取り組んでいます。
2026年10月25日 から。
評価
この issue はまだ評価されていません。
説明
Pre-flight checks
- I searched existing issues and found no duplicate.
- I understand that this proposal requires product review before implementation.
Problem to solve
El repo no tiene una política de formato Rust verificada:
- No existe
rustfmt.tomlen ninguna parte del repo. - Ningún workflow de CI corre
cargo fmt --check(revisados los 9 de.github/workflows/). - El baseline no está fmt-clean:
cargo fmt --checkfalla hoy (p. ej.src-tauri/src/wm_compat.rsysrc-tauri/src/cli_process.rstienen líneas largas sin formato).
Consecuencia observada en la práctica (PR #183, ciclo de revisión de #181): un cargo fmt -- <archivos> durante el trabajo generó ruido de formato en 29 archivos que no se tocaban (~3.700 líneas), que hubo que descartar para no inflar el diff de un PR de bugfix. Cada contribuidor decide su estilo y cualquier PR que mezcle cambios funcionales con formateo mata la revisión del diff.
Proposed solution
Tres pasos, en este orden:
- Decidir configuración (opcional): si se quiere algo distinto del default de rustfmt (p. ej.
max_widthmás generoso; varios tests actuales se escribieron con líneas >100 columnas y rustfmt los parte), definirlo enrustfmt.tomlantes de formatear. - Un commit de formateo único y aislado:
chore(style): cargo fmtsolo formato, sin mezclar con nada funcional, revisado y aterrizado solo. Así ese diff grande se lee una vez y no vuelve a aparecer. - Gate de CI:
cargo fmt --checkcomo paso enci.yml/linux-pr-ci.yml(coste en segundos) para que el formato sea requisito de PR y no decisión de cada contribuidor.
Coordinación: aterrizar después del merge de #183 (PR en vuelo) para no rebasear sobre un reformateo masivo.
Affected area
CI or automation
Scope and non-goals
Incluye: formateo de los targets Rust (src-tauri), posible rustfmt.toml, gate cargo fmt --check en CI.
No incluye: cambios de comportamiento o refactors (el formateo es solo formato), política de warnings de clippy ni otros linters, formateo del frontend (prettier/eslint, si aplica, sería propuesta aparte), ni cambios al flujo de #183/#181.
Alternatives considered
- No hacer nada / discreción por contribuidor: lleva a estilos mezclados y PRs ruidosos (observado en la práctica).
- Formatear solo archivos tocados por PR: como el baseline no está fmt-clean, sigue generando ruido en el diff.
- Gate de CI sin el commit de formateo: el check fallaría de inmediato en el baseline; no es viable sin el paso 2.
- 主要言語
- TypeScript
- スター
- 10
- フォーク
- 2
- 平均マージ
- 4時間 44分
- マージ済み PR（30日）
- 100
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
egdev6/quorb のほかの issue
-
type:feature
難易度 5/5 1週間以上 初心者へのやさしさ 8/100
メンテナーはふだん 1 日以内に返信
-
type:bug
難易度 3/5 3〜5日 初心者へのやさしさ 25/100
メンテナーはふだん 1 日以内に返信
-
type:bug
難易度 3/5 1〜2日 初心者へのやさしさ 48/100
メンテナーはふだん 1 日以内に返信
-
難易度 5/5 1週間以上 初心者へのやさしさ 35/100
メンテナーはふだん 1 日以内に返信
-
Proveedor OpenCode Go: cuotas de 5 h, semanal y mensual対応中かも @SrStamm が 1 日前に担当しました。 オープンstatus:approved
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
egdev6/quorb#187 · コメント 5 件 · 担当者 1 名 ·
メンテナーはふだん 1 日以内に返信
似ている issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
caelestia-dots/caelestia#534 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
bobadilla-tech/biasmarket.com#402 ·
メンテナーはふだん 1 日以内に返信
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
javvadivijayprasad/sel2pw#28 ·
-
Area: Infrastructure Chore Difficulty: Low Good First Issue Priority: Low
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
DouglasNeuroInformatics/OpenDataCapture#1836 ·
メンテナーはふだん 1 日以内に返信
-
Two wording fixes: the init PROVIDER comment and the confirm page's lede対応中かも @kurtbruns が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 83/100
メンテナーはふだん 1 日以内に返信