Implement AST-based dependency extraction in FormulaVisitor.calculateDependencies (markdown-template)

Aperta
  • Qualcosa non va?
#679 2 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
typescript
Ambito
backend, tooling

Direzione di ricerca

Start by reading packages/markdown-template/src/FormulaVisitor.ts and trace how calculateDependencies is called from templatemarkutil.ts and how dependencies is serialized and read back. The issue leaves the runtime parser and which identifiers count unresolved, so first settle those decisions in the discussion before implementing. Done means extracting the agreed dependencies from formula TypeScript while respecting the agreed handling of bindings and parse failures.

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

Descrizione

Stale

Summary

FormulaVisitor.calculateDependencies(tsCode) in packages/markdown-template/src/FormulaVisitor.ts is a stub (// TODO!!) that always returns []. It's invoked during TemplateMark typing (templatemarkutil.ts → templateMarkTypingGen), which sets dependencies on every FormulaDefinition / ConditionalDefinition, and the value is serialized through markdown-html (ToHtmlStringVisitor.ts writes the dependencies attribute, rules.ts reads it back). Today that attribute is always an empty array.

Continuing the working discussion with @mttrbrts

Current state / safety

Traced consumers of the field across the org:

  • markdown-transform: only written (HTML attr), read back (rules.ts), or stripped (markdown-cicero/ToCommonMarkVisitor.ts deletes it).
  • template-engine: only TemplateMarkInterpreter.ts does delete context.dependencies.

No code branches on the values, so implementing real extraction is self-contained with no regression surface — it only populates a field that is currently always empty.

Proposed approach

Extract root identifiers from the formula's TypeScript source (the param is named tsCode) via the AST rather than regex:

  • Collect root identifiers that reference template variables / model, excluding locally-bound names, function params, and built-ins.
  • Handle optional chaining (a?.b?.c → root a).
  • Return [] on parse failure or unrecognized constructs (note: this changes the current catch, which throws — flagging so it's an explicit decision).

Open questions to scope before implementation

  1. Runtime parser: typescript is currently a devDependency of markdown-template. Preference for promoting the TS compiler API to a runtime dep vs. a lighter parser (e.g. @typescript-eslint/typescript-estree)?
  2. Dependency definition: which identifier classes count — model/variable refs only, and are locally-declared bindings and function params always excluded?
  3. Cross-formula references: Devanshi noted formulas lack stable user-facing names, so these look out-of-scope for v1 — agreed to defer?

I can't make the Wednesday call, so opening this for async discussion per your
suggestion. Once (1) the runtime parser and (2) the dependency-definition
question are settled here, I'll scope the PR to those decisions.

Lingua principale
TypeScript
Stelle
86
Fork
69
Merge medio
6m
PR unite (30g)
3

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 accordproject/markdown-transform

Tutte le issue di accordproject/markdown-transform

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.