Repository navigation
fix(editor): map Salesforce Apex extensions to the apex language id - #14287
Conversation
Monaco's built-in registry already declares the 'apex' language and ships its tokenizer, registered for '.cls'. But detectLanguage resolves the language id before Monaco's own extension lookup runs, and the editor is mounted with that id as an explicit prop, so Monaco's inference never fires. Apex sources fell through to 'plaintext'. Map '.cls', '.trigger' and '.apex' onto the existing 'apex' grammar. No new grammar is added -- this only reaches the one already bundled.
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 10 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe language detector maps Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to The renderer now recognizes the listed Apex file types for syntax highlighting. No actionable merge risk is established by the supplied review context. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
I opened an issue before I found this PR - stablyai/orca#22049 |
# Conflicts: # src/renderer/src/lib/language-detect.test.ts
Also credit the duplicate fix in stablyai#22121, which reached the same change independently. Co-authored-by: Nurdaulet Bolat <204565446+nvimq@users.noreply.github.com>
`.rake`, `.ru`, `.jbuilder` and `.thor` sources opened as plaintext: the generated `monaco-language-associations.json` only carries Monaco's ruby registration (`.rb/.rbx/.rjs/.gemspec/.pp` plus `rakefile`/`Gemfile`), and that file is rewritten from Monaco by `generate-monaco-associations.mjs`, so curated entries belong in the hand-maintained `language-detect.ts` maps (same shape as the merged Apex precedent stablyai#14287). Add the four extensions plus the Guardfile/Capfile/Podfile/Brewfile/ Vagrantfile DSL filenames, with case-insensitive extension coverage and near-miss negatives (`report.rake.bak`, `ruby.rakex` stay plaintext). Fixes stablyai#24145 Generated-by: GLM-5.3-Flash (ZCode)

ELI5
Salesforce Apex files (
.clsclasses,.triggertriggers,.apexscripts) opened in Orca's editor as plain black-and-white text. Orca already ships the Apex coloring rules. It just never told the editor to use them for these file types. Now it does.What Changed
AccountService.clsorAccountTrigger.triggershowed monochrome text. Line numbers, bracket matching, and folding worked, but there was no highlighting..xml/.js/.mdfiles in the same repo highlighted normally.detectLanguage(src/renderer/src/lib/language-detect.ts), and passes it to Monaco explicitly. An explicit language overrides Monaco's own extension lookup, so Monaco's built-in.cls→apexregistration never ran, and unknown extensions fell back toplaintext. This PR adds.cls,.trigger, and.apexto Orca's map, pointing at Monaco's bundledapexgrammar. Monaco doesn't register.triggeror.apexat all, so they needed an entry either way.Why
The other option was to let Monaco guess from the file extension whenever Orca's map has no entry. That would cover more file types at once. But Orca's editor model URIs are synthetic, and each editor view (file tab, diff, conflict review, excerpts) creates its own models, so that change would touch several views and belongs in its own PR. Adding a map entry matches how
.liquid,.proto, and.jspwere added, and keepsdetectLanguagea pure lookup that doesn't depend on Monaco. No new grammar or dependency is added. Monaco loads the Apex grammar only when an Apex file is opened.Linked Issue
Fixes #22049
Supersedes #22121, which made the same fix independently later. Its author is credited as a co-author.
Visual Proof
Before (reported here):
After, dev build of this branch, files opened from the file explorer (both tabs report language
apex):Testing
I manually tested these changes locally (macOS dev build: opened a
.clsand a.triggerfrom the file explorer; both highlight as Apex)Automated tests added/updated
vitest run src/renderer/src/lib/language-detect.test.ts: 16 passed. The new case covers.cls,.trigger,.apex, and an uppercase Windows path. It fails without the map change (expected 'plaintext' to be 'apex').pnpm tc:web,oxlint,oxfmt --check,pnpm run check:code-quality:changed: pass.AI Disclosure
Maintainer follow-up commits were made with Claude (Opus 5.5).
Review
The original commit is by @bdJohnson72. Maintainer changes on top of it:
main. The test file conflicted with the.liquidtest added since; both tests are kept.Agent skill upstream boundary
docs/reference/agent-skill-sharing-upstream-boundary.mdand copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.Notes
/and\paths (tested).commongrammars, which don't include Apex, so anapexid falls back to plaintext there as before.Checklist
N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)