It'll be awesome to have full stack support for GHCJS in the future. However, for now stack's docker images do help a ton to make it easy to do development on GHCJS. Here's what I'm using for the new School of Haskell:

Have something like this in your stack.yaml:

resolver: lts-2.14
docker:
  enable: true
  repo: fpco/stack-ghcjs-build

fpco/stack-ghcjs-build is a ~4.5gb or so image, which doesn't have all of stackage installed. If you want that, there's a 16GB image with all of stackage at fpco/stack-ghcjs-full. Other images are here.

Then, you can do this to build and install ghcjs dependencies:

stack exec -- cabal --config-file=cabal-ghcjs-config update
stack exec -- cabal --config-file=cabal-ghcjs-config install --ghcjs all-the-ghcjs-stuff-i-want/ to-install/

Why the --config-file=cabal-ghcjs-config? I found it to be necessary in order to avoid dependency issues. For simpler usecases it might be fine to omit, though. This causes a new config file to be initialized and used by ghcjs, instead of using the global stackage config file used by cabal. This isn't perfect, because it means the packages shared by your server and client could have different versions. For example, you might end up with a different version of aeson than is in the stackage snapshot.

GHCJS? #337

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions