CLI: Warn when Yarn 1 is detected on a best-effort basis

[obvious-autobuild]

Why

Yarn 1 (Classic) is in maintenance mode, and Storybook's package-manager ecosystem increasingly assumes modern managers (npm, pnpm, Yarn Berry). Users on Yarn 1 currently get no signal that support is best-effort only, so avoidable install/upgrade friction goes unexplained. This adds a single, actionable, docs-linked warning — without ever blocking any CLI operation.

What

A shared warnOnYarn1 helper in code/core/src/common/js-package-manager/ that branches on PackageManagerName.YARN1, deduplicates via once.warn, uses getPrettyPackageManagerName for the label ("Yarn Classic (v1)"), and emits one line:

Yarn Classic (v1) is supported on a best-effort basis. Storybook works best with npm, pnpm, or Yarn Berry. For more information, see: https://storybook.js.org/docs/get-started/install

Two call sites, both beside existing package-manager handling:

• Init preflight (PreflightCheckCommand.ts) — placed strictly after the empty-directory branch returns, so the npm-fallback path never double-warns.
• Shared project-data path (getStorybookData.ts) — covers upgrade, doctor, automigrate, add, and the agent-facing project-info skill in one place. The warning is unconditional — per review feedback, there is no suppression option; every consumer sees it.

Deliberately excluded: the upgrade autoblock system, dev/build startup flows, and telemetry — Yarn 1 must never become a hard blocker anywhere.

How to Review

• code/core/src/common/js-package-manager/warnOnYarn1.ts — the whole behavior contract (never throws; single line; once-per-process).
• code/core/src/cli/getStorybookData.ts — the unconditional warning beside package-manager detection.
• code/lib/create-storybook/src/commands/PreflightCheckCommand.ts — placement after the empty-dir return.
• Review history: per @valentinpalkovic's review, the earlier warnOnYarn1?: boolean suppression option (and the project-info.test.ts / warnOnYarn1.test.ts files covering it) was removed in 2d9411b — the warning now always logs.
• Tests use stringContaining on plain fragments because picocolors can inject ANSI around colored text; upgrade integration tests capture process streams since the dist CLI runtime resolves its own node-logger instance that object spies can't see.

Manual testing

This is backend-only CLI logging work — no rendered UI, so visual/browser evidence is not applicable. To verify manually:

1. In a scratch folder with a package.json using yarn@^1.22 ("packageManager": "yarn@1.22.22") and no lockfile changes, run the canary CLI's storybook upgrade — expect exactly one "Yarn Classic (v1) is supported on a best-effort basis…" line and a normal, non-blocking completion.
2. Repeat in an npm/pnpm/Yarn Berry project — expect no such warning.
3. Run storybook init in an empty directory with Yarn 1 available — expect the single npm-fallback notice and no duplicate best-effort warning.

Automated coverage: 53 tests across three suites (getStorybookData chokepoint, init preflight, upgrade integration).

Test Evidence

Backend-only CLI logging work — no rendered UI, so visual evidence is not applicable. Verified locally at head 74dc6e967483177d0582339edf88430d2cab9b06: all three suites pass (53/53, includes vitest typecheck), oxlint and oxfmt clean on touched files. Acceptance-criterion evidence (tc-1–tc-6) refreshed at this head in the Obvious project.

🔗 Obvious Project · 🧵 Obvious Thread

[storybook-app-bot]

Package Benchmarks

^{Commit: 74dc6e9, ran on 14 September 2026 at 11:56:27 UTC}

No significant changes detected, all good. 👏

[obvious-autobuild]

Replying to this comment

Thanks for the report. The @storybook/vue3-vite size delta predates this PR's changes — this branch's seven files (core CLI package-manager warning + tests) do not touch vue3-vite; the delta arrived with the merge from next that carried the @react-aria/* dependency refresh (#36279). No action needed in this PR.