pull-reprint: stop touching internal Reprint state directly

[fredrikekelund]

Related issues

• Depends on Expose source layout and pull artifact status through import-metadata WordPress/reprint#436 and --target-* options for the apply-runtime command WordPress/reprint#540
• Fixes STU-2180
• Supersedes Read Reprint pull metadata through import-metadata #4401

How AI was used in this PR

Codex wrote the whole thing based on a detailed upfront plan that I drafted with Claude. The process was highly iterative.

Proposed Changes

The pull-reprint command in Studio currently both reads and writes private Reprint state. This was implemented as a temporary measure to make selective sync work, and I'm now working on making the necessary upstream changes and then adapting Studio accordingly.

Here are the specific changes in this PR:

• Studio was reading Reprint state and index files when preparing a pull. This has been replaced with Reprint's updated import-metadata command (see Expose source layout and pull artifact status through import-metadata WordPress/reprint#436).
• Eventually, Studio should use Reprint to get a file tree from the remote server. However, for now, we will rely on the same Jetpack-powered approach we already use in the pull command to get the file tree.
• Because Reprint cannot yet sync only individual file paths (see pull-files --only should support file paths, not just directories WordPress/reprint#539), the file selector has been made to only display directories. This should be reverted once we have an upstream fix in place.
• Pass --target-engine and --target-sqlite-path to the apply-runtime Reprint command. If a user pulls a remote site for the first time and deselects the database, this ensures Reprint still knows to configure the site to use a SQLite database. This part depends on --target-* options for the apply-runtime command WordPress/reprint#540.

This PR depends on WordPress/reprint#436 and WordPress/reprint#540 being included in the bundled PHAR. To make things easier for testers, I've simply committed the patched PHAR.

Testing Instructions

1. npm run cli:build
2. Create a new site for testing and cd into it
3. STUDIO_ENABLE_PULL_REPRINT=1 studiodev pull-reprint
4. Ensure that the file picker displays successfully
5. Deselect the database and ensure that the sync finishes successfully (and that the site works)
6. Ensure that a second partial file sync also finishes successfully

Pre-merge Checklist

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

[fredrikekelund]

To reiterate: I will remove this file before merging. It's here to make testing easier.

[wpmobilebot]

📊 Performance Test Results

Comparing b8ef175 vs trunk

app-size

Metric	trunk	b8ef175	Diff	Change
App Size (Mac)	1406.71 MB	1406.77 MB	+0.06 MB	⚪ 0.0%

site-editor

Metric	trunk	b8ef175	Diff	Change
load	1054 ms	1029 ms	25 ms	⚪ 0.0%

site-startup

Metric	trunk	b8ef175	Diff	Change
siteCreation	7514 ms	7557 ms	+43 ms	⚪ 0.0%
siteStartup	2877 ms	2858 ms	19 ms	⚪ 0.0%

---

Results are median values from multiple test runs.

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

[gavande1]

With the raw-scratch reset removed, how does a pull recover when raw/ is non-empty and no cursor exists? Studio does not pass --on-fs-root-nonempty, so Reprint falls back to error and throws "Filesystem root is not empty and no cursor found". Does the move to state/remotes/<md5(url)>/pull/state.json put existing scratches from older builds into exactly that state?

[fredrikekelund]

Good catch 👍

The situation was a little different when this logic was implemented in #3976, but the only realistic situation where we'd get a non-empty fs-root and no cursor today is if the Reprint API URL changes, because that's what generates the state/remotes/<md5(url)> path.

After shipping this project, that won't happen, but it will definitely happen for us engineers working on this before then, because the code flips between the "v1" and "v2" API endpoints based on availability (and we just had to revert the v2 API endpoints in Automattic/jetpack#51179).

In any case: there's no legitimate case to keep this when viewing it from the end user's perspective now. We engineers might have to do some cleanup when the Jetpack API endpoint is reinstated, but that's it.

As for --on-fs-root-nonempty – that's going away when WordPress/reprint#529 lands, so there's no point in starting to pass that.

[fredrikekelund]

Thanks for the review, @gavande1! Several good feedback items 👍 My work is a bit spread out atm. I'll try to consolidate it, but it may be best to inherit one or two of these issues into another PR.

I've pushed fixes related to the buildTreeFromRemote and downloadSkippedFiles issues. For the former, I refined how we generate the --only paths from the selection, and for the latter, I've actually dropped --filter=essential-files altogether for now. We can revisit this later.

No need to review again just yet. I'll revisit all of this tomorrow

[fredrikekelund]

@gavande1, I'll go ahead and merge this as I've worked through your initial review and to keep a handle on the number of open work threads around Reprint. Feel free to call out anything that doesn't work as expected, and I'll fold that into #4531

Thanks for staying alert in the review 👍