Spotlight testing

Spotlight testing syncs one workspace back to your repository root so you can test from the root directory instead of the workspace directory.

Use Spotlight testing when a normal run script is not a good fit because your project depends on root-directory paths, expensive local build artifacts, a fixed port, or a single local database.

Video summary: Spotlight testing demo

The video shows enabling Spotlight testing in Settings, starting Spotlight from a workspace, and running a dev server from the repository root while Conductor swaps tracked workspace changes into that root. It demonstrates switching Spotlight between workspaces and explains when root build caches, hard-coded ports, or local databases make Spotlight a better fit than normal run scripts.

Spotlight testing or run scripts

Use normal run scripts when your project can run from separate workspace directories. Run scripts are the default testing path because each workspace can start its own process, use workspace-specific paths, and avoid blocking other workspaces.

Use Spotlight testing when your project needs to execute from the repository root. Spotlight testing is a good fit for:

• Directory-dependent applications that assume they run from the repository root.
• Projects with expensive initial builds that can reuse build artifacts in the repository root.
• Apps that depend on a fixed port, one local database, or another single shared local resource.
• Apps that take a long time to start but can hot reload quickly once the root process is running.
• Dev scripts with hard-coded local values that are difficult to make workspace-specific.

Spotlight testing only tests one workspace at a time. If you only need to prevent multiple run scripts from sharing the same fixed port or database, consider nonconcurrent run script mode first.

Enable Spotlight testing

Spotlight testing is experimental. Enable it in Settings -> Experimental with Use spotlight testing.

Spotlight a workspace

When you have workspace changes ready to test, click the Spotlight button in Conductor. Conductor copies the workspace changes back to the repository root and opens a terminal there.

When you turn Spotlight mode off, Conductor restores the original repository root state.

While Spotlight is on:

• The terminal runs from the repository root, not the workspace directory.
• Tracked workspace changes are swapped into the root as the workspace changes.
• Switching Spotlight to another workspace replaces the root with that workspace's tracked changes.
• Existing root build caches and long-running processes can keep hot reloading instead of starting from scratch.

How it works

Spotlight testing watches your workspace for changes. When files change, Conductor creates a checkpoint commit of your workspace and checks it out in the repository root.

Only files tracked in git are copied back to the repository root. Build artifacts such as node_modules are not copied.

Spotlight testing is a one-way sync. Changes in the repository root are not copied back to your workspace. Edit files in the workspace so Conductor can sync them to the repository root.

Troubleshooting

If Spotlight cannot start, check whether the workspace or repository root has a rebase or merge in progress.

Finish the operation with git rebase --continue or git merge --continue, or cancel it with git rebase --abort or git merge --abort. Run the command in the directory that has the pending operation.