Skip to content

Studio CLI: Import each date-fns function from its own path - #5313

Merged
chubes4 merged 1 commit into
trunkfrom
cli/date-fns-subpaths
Oct 23, 2026
Merged

chubes4 merged 1 commit into
trunkfrom
cli/date-fns-subpaths

Conversation

@chubes4

@chubes4 chubes4 commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Related issues

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) profiled studio startup in the packaged app, found the cost, wrote the change and the test, and took the timings below. I reviewed the diff and the numbers.

Proposed Changes

The CLI keeps its npm dependencies external, so an import of the date-fns root loads every date-fns function: about 300 modules, for the 8 functions Studio uses. With the packaged app's Node and node_modules, import( 'date-fns' ) alone takes about 0.9 s; import( 'date-fns/isSameDay' ) takes about 15 ms. Every studio command paid this, because lib/snapshots.ts and lib/site-runtime-stats.ts are on the startup path.

  • Each date-fns function is imported from its own path (date-fns/format, …), in the CLI and in the two @studio/common files the CLI uses. DurationUnit stays a type-only import from the root, which is erased at build time.
  • The startup-imports test from Studio CLI: Load the MCP server only when studio mcp runs #5235 now also checks that nothing on the startup path loads the date-fns root. It fails on trunk.

Testing Instructions

  • npx vitest run apps/cli/tests/startup-imports.test.ts passes; on trunk it fails.
  • CLI unit tests (124 files, 1,241 tests) and packages/common tests (87 files, 862 tests) pass.
  • Timings on an M-series Mac, using the packaged app's resources/bin/node and resources/cli/node_modules with each build's dist/cli, runs interleaved:
Trunk This branch
studio site list --help, 12 runs median 1.13 s (0.83–3.36) median 0.53 s (0.42–1.62)
studio --version, 7 runs median 1.53 s median 0.72 s
Modules loaded by studio --version 863 621
  • The "Performance Test Results" comment on this PR should show lower siteCreation and siteStartup.

Pre-merge Checklist

  • Have you checked for TypeScript, React or other console errors?

The date-fns root loads all of its functions, about 300 modules, on
every studio command. Each function has its own path.
@wpmobilebot

Copy link
Copy Markdown
Collaborator

📊 Performance Test Results

Comparing 42d8fc2 vs trunk

app-size

Metric trunk 42d8fc2 Diff Change
App Size (Mac) 940.68 MB 940.68 MB 0.00 MB ⚪ 0.0%

site-editor

Metric trunk 42d8fc2 Diff Change
load 1213 ms 1192 ms 21 ms ⚪ 0.0%

site-startup

Metric trunk 42d8fc2 Diff Change
siteCreation 7524 ms 6494 ms 1030 ms 🟢 -13.7%
siteStartup 4382 ms 2862 ms 1520 ms 🟢 -34.7%

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

@chubes4
chubes4 merged commit 157fa55 into trunk Oct 23, 2026
14 checks passed
@chubes4
chubes4 deleted the cli/date-fns-subpaths branch October 23, 2026 04:19
import { isSameDay, isSameMonth, isSameWeek } from 'date-fns';
import { isSameDay } from 'date-fns/isSameDay';
import { isSameMonth } from 'date-fns/isSameMonth';
import { isSameWeek } from 'date-fns/isSameWeek';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this PR needs a small note in agents.md to prevent it from happening again.

chubes4 added a commit that referenced this pull request Oct 27, 2026
## Related issues

- Follows #5235, #5313 and #5316, which kept the MCP server, the
`date-fns` root and `@inquirer/prompts` off CLI startup.

## How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) profiled CLI
startup, wrote the change and the test, and measured the before/after
timings. I reviewed the diff and the measurements.

## Proposed Changes

`apps/cli/index.ts` statically imported every top-level command module,
and each module held the command's whole implementation. So every
`studio` invocation loaded the implementation of every command before
running one, including the export, import, push and pull code and its
archive, upload and certificate libraries: 1,375 dependency files from
109 packages for `studio --version`.

Each top-level command now has a `.command` module that defines the
command (name, description, options) and loads the implementation with
`await import()` in its handler, the pattern `wp` and `_events` already
use. The implementation modules keep their paths and their `runCommand`
exports, so their other callers are unchanged; each one's former handler
body is now its exported `commandHandler`.

- `studio list`, `start`, `stop`, `create` and `wp` load 520 dependency
files at startup instead of 1,375.
- Help output, unknown-command errors and option validation are
byte-identical to trunk.
- A `CommandArgs< typeof builder >` type keeps each handler typed from
its command's options.

Local timings on macOS (median of 8 alternating runs, Node 24):

| Command | trunk | this PR |
| --- | --- | --- |
| `studio --version` | 0.40 s | 0.21 s |
| `studio list` | 0.39 s | 0.23 s |
| `studio status` | 0.42 s | 0.24 s |
| `studio wp option get blogname` | 0.67 s | 0.48 s |
| `studio stop` / `start` (already in that state) | 0.44 s | 0.26 s |

The saving is a fixed cost per CLI process, so it applies to every
command the desktop app and Studio Code run through the CLI.

## Testing Instructions

- `npx vitest run --project cli apps/cli/tests/startup-imports.test.ts`:
loading what `index.ts` imports statically must not load any command
implementation. Making a `.command` module import its implementation
statically fails it.
- Build the CLI and compare `studio --help`, `studio create --help` and
`studio foo` with trunk's output.
- Time `studio list` or `studio wp option get blogname` against trunk.

## Pre-merge Checklist

- [x] Have you checked for TypeScript, React or other console errors?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants