Haskell tooling has improved considerably over the last year. With the rise of new tools supporting IDEs in Haskell, certain limitations have become apparent in the GHC API. For example, it is complicated to propagate updates between dependent packages. This problem also manifests itself in working on a cabal project. When an executable component is being used in an interactive session and then changes are made to the library, the executable’s session needs to be restarted in order to be able to call changed library functions. In my Google Summer of Code Project I have been working on extending GHC to be able to handle multiple home units at the same time. We accomplish this by maintaining a set of dynamic flags and a home package table for each unit. This will enable developers to painlessly load multiple home units into a single GHCi session. Moreover, it might prove useful for follow up conbtributions to enable GHC to work as a build server. As such, it can compile multiple packages in parallel without being restarted, using less memory in the process. These changes will improve development on various Haskell language servers by not requiring work arounds for this issue in the future. Additionally, it allows Haskell language servers and IDEs to better support multiple components and projects with a single GHC instance.