Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

CLI: every studio command spends about a second loading modules before doing any work

Open
  • Is something wrong?
#5,169 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Refactor
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
cli, performance

Research direction

Start with the CLI entry point in apps/cli/index.ts and the locale loader in packages/common/translations/index.ts; compare their current imports with the lazy-command pattern already used by wp. Then trace the remaining imports on the wp path and benchmark studio --version and studio wp option get siteurl against the issue’s baseline. Done means commands still show identical --help output and startup measurements improve without breaking locale use in the CLI, desktop app, or UI.

Written by the indexing model from the issue text.

Description

Every studio invocation, including studio wp and studio --version, spends about a second loading JavaScript before it does any work. This matters most for agents and scripts that call studio wp many times in a row.

Measurements

Production build of trunk on macOS (M-series, Node 24), medians of 5 runs:

Time
node -e 1 0.03–0.15 s
studio --version 1.16 s
studio wp option get siteurl 1.55 s
The same WP-CLI command run on Studio's PHP directly 0.63 s

So studio wp adds about 0.9 s on top of WP-CLI itself. A CPU profile shows almost no time in Studio code: it's Node resolving, reading and compiling modules.

studio --version loads 3,769 modules (22.8 MB). The biggest contributors:

  • Eagerly imported commands. apps/cli/index.ts statically imports create, list, start, stop, delete, status, push, pull, pull-reprint, import, export, ui, uninstall and mcp, so every invocation loads all of their dependencies. mcp alone pulls in the coding-agent runtime (about 1,600 modules). auth, preview, config, blueprint and wp are already lazy. This accumulated rather than being decided: yargs needs a command's definition at the root, and each command module imports its implementation next to its definition.
  • All translations at once. packages/common/translations/index.ts imports all 21 locale JSON files, which end up inlined (about 4.5 MB) in a shared chunk that every command loads. Importing that chunk on its own takes about 0.24 s more than an equivalent chunk without it.
  • Shared libraries on the wp path: zod, date-fns, yargs, chardet, semver.

Prototype

Registering the 14 eager commands lazily (name and summary at the root, the module loaded in the builder and handler, the same pattern wp already uses) gives:

Before After
Modules loaded by studio wp 3,769 634
studio --version 1.16 s 0.85 s
studio wp option get siteurl 1.55 s 1.60 s (within noise)

Every --help output stays identical. studio wp doesn't get faster from this alone, because what remains on its path is mostly the translations chunk and the shared libraries.

Suggested steps

  1. Register commands lazily.
  2. Load only the active locale's translations, instead of importing all 21 in packages/common/translations. This touches getLocaleData, which the CLI, the desktop app and the UI all use.
  3. Trace the remaining imports on the wp path and make the heavy ones dynamic.

Estimated result for studio wp: about 0.9 s, against the 0.63 s floor.

Related: #4343

How AI was used

Claude (via the Pi coding agent in a Roadie session) profiled the CLI, built the lazy-command prototype, and drafted this issue. The numbers come from local runs on a loaded machine, so treat them as approximate.

Dominant language
TypeScript
Stars
543
Forks
104
Avg merge
23h 59m
Merged PRs (30d)
276

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/studio

All issues in Automattic/studio

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.