Search code examples
flutterbuildpackagelibraries

Flutter: What is best practice for how to configure/build multiple apps that use a single private "core" library/package?

I've done a fair bit of searching here and elsewhere, but haven't found a clear answer...

I have two apps which will share considerable functionality and access the same cloud data, but are still quite distinct. A similar public example that comes to mind is Uber: one app for the driver, one app for the rider. They apps share a lot of core functionality. I think it does not makes sense to have one monolithic app that presents two significantly different UXs and sets of functionality based on the type of user... Or does it?? What are the main advantages/disadvantages to this approach?

I'm not totally sure, but to me it seems more sensible to have two separate apps which import a "core" library that contains the elements common to both apps (some data models, some UI widgets, etc.). How does one build the two apps in such a situation? Can I build both from a single Flutter project, or do I need separate projects for each app?

  1. If building from a single project, how does one configure it to build two different apps? (Using flavors doesn't seem appropriate for this; I am already building multiple flavors for each app: DEV/TEST/PROD)
  2. If building from separate projects, it seems that it should be simple to have an additional (third) separate project for the core library, which can be built/saved to a private GitHub repo. I have read that putting the core library in a separate repo can be problematic/inconvenient due to how pub caches packages. Is this still true? Is it as simple as specifying separate folders in the single repo for the three different projects? Are there other things to consider with this configuration?
Solution

  • The solution I arrived at was to use the melos package to set up my project in a mono-repo.

    This allows me to have separate top-level directories (within my project/repo) for each of my apps and for each of my libraries. A top-level configuration file for melos lists each of them, and melos enables the libraries to be 'visible' to the apps. It's a slick and simple solution that met my needs.