[github-actions]

WHY are these changes introduced?

The initConfig tests in packages/theme/src/cli/services/check.test.ts replaced the whole @shopify/cli-kit/node/fs module with stubs:

vi.mock('@shopify/cli-kit/node/fs', async () => ({
  fileExists: vi.fn(),
  writeFile: vi.fn(),
}))

They then asserted only that writeFile had been called with expect.any(String). Nothing checked that a config file was created, what it contained, or that an existing file survived — so the tests passed as long as initConfig called writeFile with any string at all. That also conflicts with the repository rule that filesystem tests must use real temporary files.

I reviewed the Main tests runs created between 2026-10-06T00:30Z and 2026-10-13T00:30Z first. The only failure in that window was app-security-commands.test.ts > formatAppSecurityCommand > the PowerShell record command reads a findings file without a byte order mark as UTF-8 in Windows PowerShell 5.1, which timed out at 13s in [Main] Node 24.1.0 in windows-latest. That flake already has an open fix in #8832, so there was no actionable, unaddressed flake left and I picked this quality issue instead.

WHAT is this pull request doing?

Drops the fs module mock from check.test.ts and runs both initConfig tests in a real temporary directory via inTemporaryDirectory:

• The existing-file test writes a .theme-check.yml first, then asserts the file is byte-for-byte unchanged and that loadConfig was never consulted, rather than asserting writeFile was not called.
• The creation test asserts the exact YAML written to disk — extends: theme-check:recommended, the node_modules/** ignore entry, and the commented-out check settings — rather than expect.any(String).

Coverage is preserved and tightened: the outputInfo/outputSuccess message assertions stay, and the contents assertion is new. The loadConfig stub remains because it reads the installed theme-check settings, which are not what these tests are about; fs is no longer mocked at all, so the rest of the file is unaffected. This removes the last fs automatic mock in the theme package, which the rule added in #8866 does not cover because this one is a factory mock.

Both tests were confirmed to fail without the behavior they assert. Replacing writeFile(filePath, ${initConfigYml}${checksYml}) with writeFile(filePath, initConfigYml) fails the creation test, and removing the fileExists early return fails the existing-file test; the old assertions passed in both cases. Validation on Linux Node 26.1.0: the file passes (17 tests), three times under --sequence.shuffle, under --pool=forks, and alongside all 18 packages/theme/src/cli/services test files (163 passed) including shuffled. nx type-check theme and ESLint on the changed file both pass. These tests are not platform-gated and the assertions avoid writeFile EOL translation and use joinPath, so they should behave the same on Windows and macOS, but I could not run those platforms locally.

How to manually test your changes?

shopify theme check --init

Checklist

• I've considered possible cross-platform impacts (Mac, Linux, Windows)
• I've considered possible documentation changes
• I've considered analytics changes to measure impact
• The change is user-facing — I've identified the correct bump type (patch for bug fixes · minor for new features · major for breaking changes) and added a changeset with pnpm changeset add