Conversation
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
sarahxsanders
force-pushed
the
monorepo
branch
from
dcac167 to
7239269
Compare
|
so my high-level thoughts are there's a lot of good stuff here on detecting monorepos, but building a new monorepo execution flow from parts of the original agent-runner is too complex and difficult to maintain. you're doing some mad scientists stuff with parallel wizard runs but we're not ready for Gas Town-style agent swarms (yet) creating separate log files for an unknown amount of apps in a monorepo was the warning sign that we need to turn around imo I think if we only focus on detection logic, we can rebuild it quickly and cleanly for the new TUI what do you think @sarahxsanders |
|
three cheers to the mad scientist, this is such valuable exploration! |
|
@edwinyjlim gonna move this to draft for now :) explorations confirmed monorepo is possible, agree that to release this, we should revisit after shipping more important things! |
3 participants
presenting: v1 wizard monorepo skill
when you run the wizard in a monorepo:
What's new
monorepo orchestration:
monorepo-flow.tsthree-phase execution model:
shared setup (OAuth, region, checks) run once and passed to each agent
Workspace detection:
workspace-detection.tsdetects workspaces using a two pass system:
Turborepo is a label upgrade, not its own detector
App filtering:
app-detection.tsnot everything in a monorepo is an app. this filters out library package, dev tool environments, and projects that aren't real apps
uses language-specific signals (entry points, start/dev scripts w/ real dependencies), framework integrations bypass this entirely as their detection signals are app signals
PostHog detection:
posthog-detection.tsFlags if PostHog is already configured for projects in a monorepo
Nx hoisted dependency support
Nx monorepos hoist all dependencies to the root package.json,.
tryGetPackageJsonnow merges root deps when local package.json has zero whenworkspaceRootDiris set (pnpm/yarn/npm workspaces unaffected)Remix as React Router
Remix v2 apps list
@remix-run/reactnotreact-routerbut they are React Router 7 🙃 addedalternatePackageNamesto the framework config so detection/version checks/etc. all recognize RemixDetect Gatsby
Since we don't have a full Gatsby skill yet, I set detection as a JS Web app
What's changed
agent-runner.tssplit the monolithic function into composable phases:
runSharedSetup()runPreflight()runAgentWizard()when called without a
modeargument (single project), behavior is UNCHANGED from main today. Decomposition here is only additivealso, errors now throw
DisplayedErrorinstead ofprocess.exit(1)so the monorepo orchestrator can keep going when one project failsTerminal output:
clack.ts(this may be irrelevant now w/ TUI updates)Added
withSilentOutput(), a proxy that turns clack into no-ops during MONOREPO execution only. this prevents terminal garbage from multiple agents running at the same timethis is never called in single-project mode
Logging:
debug.tsadded AsyncLocalStorage for per-project log files. each agent write to its own log. this just feels the most organized way to handle this/discover these files later if you need.
falls back to the existing module-level log path for single project mode
Framework configs
glob-patterns.tsno behavior change here
Detection order
javascript_webnow requires a browser signal to avoid claiming server-only projectsjavascript_nodeexcludes known framework packages so the catch-all doesn't claim Next.js/Nuxt/etc.