Stop declaring yaml directly in theme (use already-present js-yaml)

[amcaplan]

Stops @shopify/theme from declaring yaml as a direct dependency, which is the source of the recurring Dependabot version-update churn (56 bumps / 24mo — theme was the only package in the repo declaring it directly).

This is not a tree-level removal: yaml remains a transitive dependency via @shopify/theme-check-node, so it stays in the lockfile and a future security advisory could still trigger a PR. The win is narrower — eliminating the routine weekly bumps, since npm version updates only touch deps explicitly declared in a manifest.

The YAML.stringify calls in theme-check output are switched to js-yaml's dump. js-yaml is not new to the runtime tree — it's already a production transitive dep of theme via @shopify/cli-kit → @apidevtools/json-schema-ref-parser (js-yaml: ^4.1.0), so nothing extra is installed. It's also far more stable (~2 releases in 4 years vs. ~18 for yaml since mid-2024), so it won't reproduce the churn.

Net direct runtime deps for theme: unchanged (one-for-one swap). The only true addition is the dev-only @types/js-yaml.

Validation:

• Output equivalence verified
• Snapshot parity maintained
• Type checks and linting pass
• 588 theme tests run and pass

🤖 Automated dependency-removal initiative — AI-generated draft, needs human review.

[Copilot]

Pull request overview

This PR updates @shopify/theme to stop using the yaml package and instead generate YAML output via js-yaml’s dump, aiming to reduce direct dependency churn in the theme package.

Changes:

• Replace yaml’s stringify usage in theme-check CLI output with js-yaml’s dump.
• Update packages/theme/package.json dependencies/devDependencies accordingly.
• Regenerate pnpm-lock.yaml to reflect dependency changes (and additional lockfile normalization).

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated 1 comment.

File	Description
pnpm-lock.yaml	Adds js-yaml / @types/js-yaml for packages/theme and updates lock entries.
packages/theme/src/cli/services/check.ts	Switches YAML serialization calls from yaml to js-yaml.
packages/theme/package.json	Replaces yaml dependency with js-yaml and adds @types/js-yaml.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[amcaplan]

Thanks for flagging — I checked this carefully and it's safe as written.

js-yaml@4.1.1 (the version we pin to) is dual-package, not CJS-only. Its exports map resolves the import condition to a real ESM build:

"exports": { ".": { "import": "./dist/js-yaml.mjs", "require": "./index.js" } }

and dist/js-yaml.mjs ends with a genuine named export — export { ..., dump, load, loadAll, ... }. So Node's ESM loader selects the .mjs directly and dump is a true named export; there's no CJS named-export heuristic in play and no "Named export 'dump' not found" risk.

Verified at runtime — a pure-ESM import { dump as yamlDump } from 'js-yaml' from this package resolves 4.1.1 with typeof dump === 'function' and produces correct YAML.

Worth noting the concern would have applied to 4.1.0, which is pure CJS — 4.1.1 is the release that added the ESM build, and we pin to 4.1.1 exactly.

[gonzaloriestra]

What's the benefit of this change? We are not removing a dependency, but adding a new one 🤔

• yaml is still a transitive dependency of 8 packages
• js-yaml was a transitive dependency only for dev, but now we are adding it as a new direct runtime dependency

[amcaplan]

@gonzaloriestra fair question, and you're right that this isn't a true removal — the title oversells it. yaml stays in the tree as a transitive dep of @shopify/theme-check-node (and theme-language-server-node → theme-check-node). The goal here is narrower: kill the Dependabot version-update churn (the 56 bumps / 24mo), not shrink the installed tree.

Why dropping the direct declaration achieves that:

• theme was the only package in the repo declaring yaml directly. npm version updates (the weekly scheduled ones) only bump deps explicitly defined in a manifest — transitive deps aren't eligible, npm doesn't even support dependency-type: indirect, and we have no allow override. So once theme stops declaring yaml, those weekly bumps stop.
• Caveat for completeness: because yaml stays in the lockfile transitively, a future yaml security advisory could still open a PR (security updates do traverse the lockfile). But that's a fix you'd want regardless — not routine churn.

On js-yaml being "new":

• It's not new to the runtime tree — it's already a production transitive dep of theme via @shopify/cli-kit → @apidevtools/json-schema-ref-parser (js-yaml: ^4.1.0). So nothing extra gets installed; this just leans on a package that's already there.
• It's also far more stable: yaml shipped ~18 releases since mid-2024, vs. ~2 for js-yaml in the last 4 years — so it won't reproduce the churn.
• Net direct runtime deps for theme: unchanged (one-for-one swap). The only true addition is the dev-only @types/js-yaml.

I'll retitle to something like "Stop declaring yaml directly in theme (use already-present js-yaml)" so it doesn't imply a tree-level removal.

---

🤖 This reply was drafted by Claude (AI-generated) and reviewed by me.

[gonzaloriestra]

Again: "56 bumps / 24mo" is not right. Yaml is grouped with other deps in PRs like this that are not very frequent. All these PRs are based on that "Dependabot churn" that is actually not a problem in my opinion...

About this one, I was wrong about js-yaml, it's not a new runtime dependency. But I still don't see the point of switching from one to another.

[amcaplan]

@gonzaloriestra we have a weekly dependabot job that seems to bump everything that is a direct (not transitive) dependency. The less noise there is in those PRs, the more confident we can feel just keeping everything up to date... and the less far behind we are when inevitably some package has a security issue and we are forced to catch up immediately.

[gonzaloriestra]

That PR includes upgrades for 40 small dependencies. With this change, instead of upgrading yaml, it will upgrade js-yaml. It's true that it has less releases, but is that a good thing? Is it decisive to have 39 dependencies to update instead of 40? Also, js-yaml has a transitive dependency. And if there's a security issue with yaml, then we will need to upgrade it anyway.

So if we are able to completely remove a dependency, great. But I don't see the point of just switching one for another if it's working well.

[github-actions]

This PR seems inactive. If it's still relevant, please add a comment saying so. Otherwise, take no action.
→ If there's no activity within a week, then a bot will automatically close this.
Thanks for helping to improve Shopify's dev tooling and experience.