Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Design and implement source-aware authoring edit previews

Aperta
#458 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust, typescript

Direzione di ricerca

Start by reading site/architecture/styling-ir-roadmap.md and the context in roadmap issue #456, then inspect the compiler, type, and boundary test areas mentioned in the acceptance criteria. Define the separately versioned authoring contract, source revision and ownership errors, exact preview patch, diagnostics, and before/after behavior while preserving canonical Rust semantics. Done means the preview is non-writing, stale-source checks work, the listed cases are tested, documentation passes, and authoring code does not enter runtime or static bundles.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Goal

Add a source-aware edit preview for visual editors, separate from execution Manifest v1 and separate from a file-writing command.

Roadmap: #456. Design context: site/architecture/styling-ir-roadmap.md. Source provenance from the public report proposal is a prerequisite.

Concrete use case

An editor proposes changing only the second color declaration inside an imported @utilities badge definition while retaining an earlier fallback declaration and a following native font-size: 0.875rem declaration. Preview identifies the owning file/range/revision, exact patch, diagnostics, and before/after behavior for an explicit class corpus. A later write is performed by the host only after checking the same revision.

Ownership and compatibility

  • Compiler/project owns source selection and graph orchestration; Rust owns parsing, edit targeting and lowering. An authoring contract must be separately versioned and stay out of runtime/Manifest payloads.
  • Specify input/output schema, source revision rule, stale/missing/read-only owner errors, and write authorization boundaries before implementation. Do not assume universal stable node IDs or a general lossless AST.
  • Additive 2.x API; never silently edit a different source or treat a successful preview as permission to write.

Acceptance criteria

  • Preview changes no source file. Exact patch and affected definition are reviewable; source changed between selection and preview is rejected.
  • Tests preserve duplicate declarations, comments/formatting around the edit, native declaration and conditional boundaries, imported ownership, native CSS, and diagnostics on an invalid edit.
  • Accepted previews recompile through the canonical Rust semantics and report finite before/after behavior; unsupported comparisons remain explicitly unknown.
  • Compiler/type/boundary tests and site documentation pass; unused authoring code does not increase runtime or static bundles.
Lingua principale
TypeScript
Stelle
2k
Fork
44
Merge medio
1g 3h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di master-co/css

Tutte le issue di master-co/css

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.