feat(NO-JIRA): add pnpm support to shared frontend workflows

[bobobowis]

Overview

Jira: NOJIRA-1

Extends shared reusable frontend workflows and setup-node-with-cache to support pnpm-based repos alongside existing Yarn consumers. First consumer: admin-home.

All changes are additive — Yarn behavior is untouched. Repos opt in via package-manager: pnpm. pnpm callers pass all commands explicitly (no dynamic defaults).

Changes

• Add package-manager input (yarn|pnpm, default: yarn) to setup-node-with-cache, frontend-pr-workflow, frontend-deploy-workflow, sonarcloud-scan, and the three run-cypress-*/run-playwright-visual shared-actions
• Install pnpm via pnpm/action-setup@v4 (skipped when asdf manages it)
• Branch all PM-specific logic: cache paths, cache key (pnpm-lock.yaml), integrity check (.modules.yaml vs .yarn-integrity), install command (pnpm install --frozen-lockfile), and postinstall step
• pnpm cache key prefix pnpm- isolates from yarn caches — no cross-PM cache pollution
• Fix asdf reshim: asdf reshim pnpm when package-manager: pnpm, asdf reshim yarn otherwise
• Clarify cache-mode input description to "package manager cache" across all files
• Update README and CACHE-STRATEGY-GUIDE with pnpm cache mode docs

Backward compatibility

Zero changes required from existing Yarn callers — all new inputs default to yarn.

How to use (pnpm repo)

uses: Typeform/.github/.github/workflows/frontend-pr-workflow.yml@v1
with:
  package-manager: 'pnpm'
  cache-mode: 'node_modules-only'   # or 'full' for pnpm workspaces
  build-command: 'pnpm run dist:preview'
  clean-command: 'pnpm run clean'
  deploy-command: 'pnpm run deploy:preview'
  # ... all other commands passed explicitly

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[bobobowis]

This will be removed before merging. It was done to simplify testing scenarios in the following repos: admin-home, smart-forms-builder, paprikations, performance-analytics

[kb-typeform]

🐛 Bug: $PM install --frozen-lockfile runs inside the Jarvis checkout — but Typeform/jarvis has yarn.lock, no pnpm-lock.yaml.

Caller with package-manager: pnpm and a non-empty jarvis-branch will execute pnpm install --frozen-lockfile in a yarn-locked repo:

• pnpm ≥7: hard-fails with ERR_PNPM_NO_LOCKFILE.
• pnpm <7: silently generates a fresh install from package.json → dep tree diverges from what yarn produced → subtle version drift in linked @typeform/jarvis.

The caller's PM ≠ the linked dep source repo's PM. Coupling them assumes both share PM, but Jarvis stays yarn until separately migrated.

Suggested fix — pin Jarvis-side install to yarn regardless of caller PM; keep $PM only for the consumer-side link:

cd "$JARVIS_DIR"
yarn install --frozen-lockfile
yarn link
cd $GITHUB_WORKSPACE
$PM link @typeform/jarvis

Or auto-detect:

cd "$JARVIS_DIR"
if [ -f "pnpm-lock.yaml" ]; then
  pnpm install --frozen-lockfile
  pnpm link
else
  yarn install --frozen-lockfile
  yarn link
fi

Same issue applies to the ACT=true local-testing branch above (cd .../jarvis && $PM link) if the local Jarvis checkout is yarn-installed.

[kb-typeform]

📝 Nit — yarn behavior change, low-risk but avoidable.

Before: yarn playwright install --with-deps — direct bin lookup via node_modules/.bin/playwright.

After: yarn exec playwright install --with-deps — Yarn 1 exec subcommand.

Existing yarn callers here are Yarn 1 classic (admin-home .tool-versions: yarn 1.22.19; workflow pins yarn@1.22.22).

Yarn 1 exec supports arg passthrough for non-yarn flags. --with-deps doesn't collide with any yarn-known flag → most likely works fine.

Still worth branching by PM:

1. Zero risk vs. non-zero risk — no benefit from changing yarn form.
2. Grep-audit clarity — future readers see the exact call.
3. Skips extra yarn exec process hop.

if [ "$PM" = "pnpm" ]; then
  pnpm exec playwright install --with-deps
else
  yarn playwright install --with-deps
fi

[kb-typeform]

🔧 Silent alias masks user error.

When package-manager: pnpm + cache-mode: yarn-cache-only, action treats it as pnpm-store-only. Two problems:

1. User-error masking. Caller misconfigures — copied yaml from a yarn repo, forgot to swap cache-mode. Should surface loudly, not silently rewrite semantics. When same caller flips package-manager: yarn back later, cache behavior changes without them touching cache-mode → confusing.

2. Cache key drift. key-suffix=-$CACHE_MODE appended downstream produces key ...-pnpm-<hash>-yarn-cache-only — pnpm store cached under yarn-shaped key. actions/caches UI shows key that lies about content, grep-audits misleading.

3. Asymmetric hole. yarn branch at line 121 has no case for pnpm-store-only → falls to full silently. So pnpm→yarn direction fails one way (default fallthrough), yarn→pnpm direction aliases. Neither errors.

Fix — fail loud on mismatch:

"pnpm-store-only") PATHS="$PNPM_STORE" ;;
"yarn-cache-only")
  echo "::error::cache-mode 'yarn-cache-only' invalid when package-manager=pnpm. Use 'pnpm-store-only' or 'full'."
  exit 1
  ;;

Mirror the guard in the yarn case for pnpm-store-only.

[kb-typeform]

🔧 Unpinned pnpm — reproducibility hole.

yarn side pins to 1.22.22; pnpm side grabs latest. Asymmetric.

Failure modes:

1. Runner-to-runner drift. Same PR yields different pnpm across reruns after any pnpm release. pnpm install --frozen-lockfile semantics evolved across v6→v7→v8→v9→v10 (lockfile v6/v9 format, workspace-protocol handling, packageExtensions). Silent behavior change without any code delta.

2. pnpm init interactive prompt. Non-interactive default only in pnpm v7+. Older versions prompt → hangs CI or takes defaults inconsistently.

3. Lockfile format regression. Consumer commits pnpm-lock.yaml generated with v8 (format 6.0). Runner installs v10 next month → regenerates in 9.0 format on any pnpm install without --frozen-lockfile → downstream tooling breaks.

4. Debugging noise. "Worked yesterday, fails today" with no code change — pnpm major shipped overnight.

Fix (minimum):

npm install -g pnpm@9.15.0   # match consumer repos

Better — mirror the yarn pin as a workflow input:

inputs:
  pnpm-version:
    default: '9.15.0'

Best — reuse pnpm/action-setup@v4 like setup-node-with-cache does, so version resolution honors consumer's packageManager field in package.json. One code path, deterministic.

[sonarqubecloud]

Quality Gate passed

Issues
27 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud