[ANN] Stack 2.15.1

See https://haskellstack.org/ for installation and upgrade instructions.

Release notes:

  • After an upgrade from an earlier version of Stack, on first use only, Stack 2.15.1 may warn that it had trouble loading the CompilerPaths cache.
  • The hash used as a key for Stack’s pre-compiled package cache has changed, following the dropping of support for Cabal versions older than

Changes since v2.13.1:

Behavior changes:

  • Stack does not leave *.hi or *.o files in the setup-exe-src directory of the Stack root, and deletes any corresponding to a setup-<hash>.hs or setup-shim-<hash>.hs file, to avoid GHC issue #21250.
  • If Stack’s Nix integration is not enabled, Stack will notify the user if a nix executable is on the PATH. This usually indicates the Nix package manager is available. In YAML configuration files, the notify-if-nix-on-path key is introduced, to allow the notification to be muted if unwanted.
  • Drop support for Intero (end of life in November 2019).
  • stack path --stack-root no longer sets up Stack’s environment and does not load Stack’s configuration.
  • Stack no longer locks on configuration, so packages (remote and local) can be configured in parallel. This increases the effective concurrency of builds that before would use fewer threads. Reconsider your --jobs setting accordingly. See #84.
  • Stack warns that its support for Cabal versions before is deprecated and may be removed in the next version of Stack. Removal would mean that projects using snapshots earlier than lts-12.0 or nightly-2018-03-18 (GHC 8.4.1) might no longer build. See #6377.
  • If Stack’s --resolver option is not specified, Stack’s unpack command with a package name will seek to update the package index before seeking to download the most recent version of the package in the index.
  • If the version of Cabal (the library) provided with the specified GHC can copy specific components, Stack will copy only the components built and will not build all executable components at least once.

Other enhancements:

  • Consider GHC 9.8 to be a tested compiler and remove warnings.
  • Stack can build packages with dependencies on public sub-libraries of other packages.
  • Add flag --no-init to Stack’s new command to skip the initialisation of the newly-created project for use with Stack.
  • The HTML file paths produced at the end of stack haddock are printed on separate lines and without a trailing dot.
  • Add option of the form --doctest-option=<argument> to stack build, where doctest is a program recognised by versions of the Cabal library from
  • Experimental: Add flag --haddock-for-hackage to Stack’s build command (including the haddock synonym for build --haddock) to enable building local packages with flags to generate Haddock documentation, and an archive file, suitable for upload to Hackage. The form of the Haddock documentation generated for other packages is unaffected.
  • Experimental: Add flag --documentation (-d for short) to Stack’s upload command to allow uploading of documentation for packages to Hackage.
  • stack new no longer rejects project templates that specify a package.yaml in a subdirectory of the project directory.
  • Stack will notify the user if Stack has not been tested with the version of GHC that is being user or a version of Cabal (the library) that has been found. In YAML configuration files, the notify-if-ghc-untested and notify-if-cabal-untested keys are introduced, to allow the notification to be muted if unwanted.
  • The compiler version is included in Stack’s build message (e.g. stack> build (lib + exe + test) with ghc-9.6.4).
  • Add flag --candidate to Stack’s unpack command, to allow package candidates to be unpacked locally.
  • Stack will notify the user if a specified architecture value is unknown to Cabal (the library). In YAML configuration files, the notify-if-arch-unknown key is introduced, to allow the notification to be muted if unwanted.
  • Add option --filter <item> to Stack’s ls dependencies text command to filter out an item from the results, if present. The item can be $locals for all local packages.
  • Add option --snapshot as synonym for --resolver.
  • Add the config set snapshot command, corresponding to the config set resolver command.

Bug fixes:

  • Fix the Curator instance of ToJSON, as regards expect-haddock-failure.
  • Better error message if a resolver: or snapshot: value is, in error, a YAML number.
  • Stack accepts all package names that are, in fact, acceptable to Cabal.
  • Stack’s sdist command can check packages with names that include non-ASCII characters.

Thanks to all our contributors for this release:

  • Bryan Richter
  • Dash Lu
  • Jason Shipman
  • Marco Zocca
  • Markus Schirp
  • Mike Pilgrem
  • Olivier Benz
  • Phil de Joux
  • theophilebatoz

How does this look in practice? I found PR 6343 but it doesn’t mention any example packages.


It means you can use this type of dependency in your cabal file :

Where the project in question has this type of cabal file :


An experimental new feature is --haddock-for-hackage. For example, Hackage cannot build Stack’s Haddock documentation but Stack can build it. I can build it, and add the Haddock documentation to Hackage (and have now done so), with (in the root directory of the stack package):

stack purge # No harm in starting with a clean slate
stack haddock --haddock-for-hackage # Build docs in the format Hackage needs
stack upload . --documentation # Upload docs only to Hackage