Skip to content

CONCEPT Cited by 1 source

Headless IDE inspection

Definition

Headless IDE inspection is the technique of taking an IDE tool that was designed to run interactively — a refactor, an inspection, a code-action — and driving it from a server process with no UI attached. The IDE's core libraries are instantiated; the UI shell is not. Runs in CI, on a server fleet, under a cron, or inside a custom tool.

Why it matters

Most IDE inspections / refactorings carry substantial business logic (type resolution, cross-file symbol lookup, language- specific fixups) that's expensive to re-implement outside the IDE. Making them headless inverts the cost calculation: you get the IDE's logic for free, at the cost of hosting the IDE's runtime on a server.

Concrete benefits named in the Meta post:

  • Parallelism — "the headless approach allowed us to translate multiple files at once."
  • CI / cron integration — the IDE tool becomes a scriptable step.
  • Unblocking expensive post-steps — "it unblocked all sorts of helpful but time-consuming steps, like the 'build and fix errors' process detailed below."
  • Per-file developer cost → ~0 — developers no longer click the button themselves; a cron produces the diffs.

Trade-offs:

  • Total wall-clock up — a Kotlinator conversion takes ~30 minutes end-to-end vs a couple of minutes locally, because of the wrapping pipeline and the headless IDE spin-up.
  • Plumbing — requires an IntelliJ plugin (for the JetBrains case) whose class extends ApplicationStarter and invokes the inspection programmatically.

Canonical wiki instance — Meta's headless J2K

Meta collaborated with JetBrains' J2K maintainer to build a headless version of J2K by:

  1. Creating an IntelliJ plugin.
  2. Extending ApplicationStarter.
  3. Calling JavaToKotlinConverter directly — the same class invoked by the in-IDE conversion button.

This is the unlock that made the entire Kotlinator pipeline possible.

Seen in

Last updated · 319 distilled / 1,201 read