## Summary
- Reject unsupported Node.js versions before loading the CLI bundle.
- Report the declared engine range and detected version with an
install-and-retry instruction.
- Keep the runtime check aligned with `package.json#engines.node`.
## Root cause
The CLI declares Node.js 22.12+ but did not enforce that requirement at
startup. Package managers can warn and continue, allowing unsupported
runtimes to reach preview code. Execa 10 then initializes
`Set.prototype.union()`, which is unavailable in Node 20 and causes the
delayed `screenshot.responsive` failure.
## Technical choices
- Validate the runtime directly at the published executable boundary.
- Parse the declared engine range with `semver`.
- Dynamically import the CLI only after the runtime passes validation.
- Report the exact engine range rather than assuming every valid range
means “or newer.”
- Test the published `bin.js` in a subprocess with an injected
unsupported runtime version.
- Write the actionable startup failure to stderr and exit nonzero.
- No migrations or public API changes.
## Checklist
- [x] Add the startup runtime guard.
- [x] Add executable-level regression coverage for unsupported Node.js.
- [x] Verify the supported runtime still loads the CLI.
- [x] Review fixture impact; no fixture inputs or outputs are affected.
- [x] Review authoritative documentation; `docs/university/cli.md`
already requires Node.js 22.12+, so no update is needed.
- [ ] Run agent evaluations — not run because the requester declined
them.
## Verification
- Published and local launcher tests: 4 passed.
- CLI typecheck: passed.
- Targeted lint and formatting: passed.
- CLI production build: passed.
- Node.js 18.16.1 and 20.12.2 executable checks: exited 1 before loading
the CLI, reported the `>=22.12.0` requirement, and wrote no stdout.
- Node.js 22 executable check: CLI loaded successfully.
- Package dry run: includes the guarded `bin.js` and no separate runtime
helper.
- `git diff --check`: passed.
- The executable-level regression test was confirmed to fail against the
previous message/implementation and pass after the direct guard was
applied.
## Known limitation
An MCP client may wrap a subprocess startup failure in its own UI, but
the CLI now provides the actionable requirement and installation
instruction on stderr before any tool runs.
Closes#6190
This PR expands Webstudio MCP and CLI into a more complete agent
authoring interface. Agents can discover project capabilities, edit real
Webstudio content, use data/resources, verify visual output, and report
useful issues when workflows fail.
## MCP User Capabilities
- Create, update, duplicate, reorder, and delete pages.
- Create pages from templates and manage reusable page templates.
- Inspect project pages, instances, props, styles, assets, variables,
resources, and metadata.
- Insert Webstudio components and authored JSX fragments into pages.
- Edit text, props, styles, breakpoints, design tokens, and CSS
variables.
- Update page metadata, SEO fields, redirects, marketplace metadata, and
project settings.
- Create and use static data variables.
- Create and use dynamic resources fetched over HTTP.
- Use REST, GraphQL, and built-in system resources in authored pages.
- Bind data variables and resources to visible page content.
- Create resource-backed pages such as sitemap XML, structured SEO data,
and API-driven content sections.
- Preview current project state without requiring a publish step.
- Capture screenshots for visual verification.
- Verify responsive designs across desktop, tablet, and mobile
breakpoints.
- Use screenshot diff and OCR-style checks to inspect rendered output.
- Reset and refresh local MCP project state when needed.
- Discover available CLI/MCP commands from generated manuals.
- Use clearer examples for resources, data variables, JSX authoring,
previewing, and visual checks.
- Read marketplace product metadata without requiring a full project
snapshot.
- Get safer guidance when using low-level patch tools.
- Get a ready-to-copy Discord report template when MCP/CLI behavior is
confusing or broken.
Finally figured out how to leverage node conditions to run webstudio cli
in fixtures without rebuilding it on every change.
Import conditions is another thing which allows
to constrain not exposed modules but internal ones.
Now to run cli locally it should be have this env
which is basically same we do with vite.
Works for both import and export conditions.
```
NODE_OPTIONS='--conditions=webstudio --import=tsx' webstudio
```
Here changed build command to bundle all cli packages so we would not
need to resolve .js extensions in es modules. This will fix ubuntu,
windows and node 20 usages.
## Description
Fixes local installation of cli
The issue was that at `pnpm install`
`./lib/bin.js` wasn't exists.
Solution is to create it and forward all calls to `./lib/bin`
## Steps for reproduction
1. click button
2. expect xyz
## Code Review
- [ ] hi @kof, I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
- test it on preview
## Before requesting a review
- [ ] made a self-review
- [ ] added inline comments where things may be not obvious (the "why",
not "what")
## Before merging
- [ ] tested locally and on preview environment (preview dev login:
5de6)
- [ ] updated [test
cases](https://github.com/webstudio-is/webstudio/blob/main/apps/builder/docs/test-cases.md)
document
- [ ] added tests
- [ ] if any new env variables are added, added them to `.env.example`
and the `builder/env-check.js` if mandatory
## Description
This PR adds a default favicon for the projects generated using `cli`.
Now there is a another build step, which holds all the default image
assets. And stores them as `base64`. And writes back to the destination
project.
The two things that are handled are
- favicon
- no-warnings flag to disable warnings when using cli
## Code Review
- [ ] hi @TrySound , I need you to do
- conceptual review (architecture, feature-correctness)
- detailed review (read every line)
## Before requesting a review
- [x] made a self-review
- [x] added inline comments where things may be not obvious (the "why",
not "what")
Oleg Isonen