Migrating a PureScript app from spago 0.12 to 0.13: Resolver Selection Uncertainty

Direct Answer

For a small PureScript application, the most stable resolver is the published package set that matches the compiler version your code already builds with. Do not assume a snapshot name such as lts-18.0 is valid for spago; that resembles Stackage naming and may not exist in your spago 0.13 release. If your project uses a custom dependency set, a custom package-set import is likely safer than forcing a named resolver.

What Is Confirmed vs. Likely

Confirmed: Older spago configurations typically separate the package set (via a packages or packages.dhall import, often hash-pinned) from the dependencies list. A resolver field is a convenience for naming that package set/toolchain, but exact syntax and defaults are release-specific.

Likely but unverified for your build: If both resolver and the deprecated packages field are present, spago may merge them, override one, or error. Do not rely on precedence. The final lock file is whatever the resolver/package-set input produces after spago update. Keep one source of truth by removing the deprecated field and committing the regenerated lock file.

Reproducibility Impact

Changing resolvers changes the transitive dependency graph and may pull in a different compiler. Observable effects include a rewritten spago.lock, different package versions, and potential type-level breakage. Reproducibility is preserved only when the spago version, compiler version, package-set/resolver, and lock file are all pinned and CI uses the same commands.

Scoped Migration Steps

1. Record the current toolchain and lock state before any edit:

   spago version
   purs --version
   git log --oneline -1 -- spago.lock

2. Identify the package set your 0.12 build already uses. Choose the equivalent resolver that targets the same compiler version; do not jump to the newest snapshot.
3. Remove the deprecated packages field and replace it with the single resolver equivalent documented for your exact spago 0.13 release.
4. Run spago update on a branch, then build and test:

   spago build
   spago test

5. Diff the lock file to confirm only intended package-set/compiler changes occurred. Commit the lock file, then deploy.

One Missing Diagnostic

Does your 0.12 project already have a committed spago.lock and a pinned compiler? If not, snapshot selection alone will not make the upgrade reproducible. Pin the compiler and regenerate a lock file from the current package set before changing the resolver.