Repository navigation
Lazy-load the Code tab grammar from the Dag's stored language - #74643
Conversation
Dag importers are pluggable, so core cannot list every language an importer may store in dag_code.language. Registering monaco's lazy grammar loaders lets the Code tab highlight any language monaco ships, fetching a grammar only when a Dag source first uses it.
f6279a0 to
5cb74b2
Compare
ashb
left a comment
There was a problem hiding this comment.
So how does this work with the compiled assets? Do those monaco editr languages still get build and compiled/minified/fingerprinted etc?
Yes, they go through the normal Vite production build like everything else. They're compiled, minified and fingerprinted, and shipped in ui/dist inside the airflow-core What changes is how they're split into files:
Before, only five grammar files (Python, TypeScript, Java, Go, YAML) were built, and the editor loaded all of them up front. Now all 89 grammar files are built: about 490 |
Backport failed to create: v3-4-test. View the failure log Run detailsNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
You can attempt to backport this manually by running: cherry_picker 518f8d2 v3-4-testThis should apply the commit to the v3-4-test branch and leave the commit in conflict state marking After you have resolved the conflicts, you can continue the backport process by running: cherry_picker --continueIf you don't have cherry-picker installed, see the installation guide. |
Backport successfully created: v3-4-testNote: As of Merging PRs targeted for Airflow 3.X In matter of doubt please ask in #release-management Slack channel.
|
…uage (#74643) (#74987) Dag importers are pluggable, so core cannot list every language an importer may store in dag_code.language. Registering monaco's lazy grammar loaders lets the Code tab highlight any language monaco ships, fetching a grammar only when a Dag source first uses it. (cherry picked from commit 518f8d2) Co-authored-by: Pierre Jeambrun <pierrejbrun@gmail.com>
Follow-up to #74633.
Dag importers are pluggable: the YAML importer (#74586), the Go/Java/TypeScript coordinators, and any third-party importer each store their own language id in
dag_code.language. Core can't know that list, so hardcoding grammars in the UI means a custom importer (say ajsonorrustone) gets plain-text Dag source in the Code tab until someone patches the UI.Monaco already ships a lazy registration for every Monarch grammar it bundles. Registering that instead lets the Code tab highlight whatever language the API returns, fetching a grammar chunk only the first time a Dag source uses it. The UI stops listing grammars and no longer loads the Go/Java/TypeScript/YAML grammars up front for Python-only deployments. Python keeps the patched f-string grammar (#67986), now loaded lazily too.
Unknown ids (for example the
"text"placeholder written when a source can't be read) still fall back to plain text.Python grammar is always loaded when opening the code tab (no python at all is very unlikely). Opening a YAML Dag loads the YAML grammar chunk in addition. (Same for other sdk languages)
Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 5.5) following the guidelines