I'm not worried about these packages, but about the Cabal code base itself.
The Cabal code base hardly creates CompilerId directly, in almost all cases the change is ignoring the third field. This is where CompilerId is created: All existing flavours add Nothing, 6x one-line change: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... Distribution.PackageDescription.Check uses it, but only for checking that the base range is bounded, not with a real compiler, but with buildCompiler with no version: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... buildCompilerId uses it (buildCompilerId is never used in Cabal, cabal-install and hackage), a better change would be to find the subcompiler if buildCompilerFlavor is GHCJS, but just adding Nothing makes it do the right thing for all existing compilers: - https://github.com/ghcjs/cabal/commit/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d... The other changes are the direct intended changes: Updated flag resolution, parsing/printing CompilerId, and getting the shared library filename from a CompilerId