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/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L15R109

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/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L2L1240

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/ce3c18aedbc4fbf58b150f10690aa5dca6ab0d72#L1R137

The other changes are the direct intended changes: Updated flag resolution, parsing/printing CompilerId, and getting the shared library filename from a CompilerId