🛠️ [TASK] : Clean up Flutter project, so it is self contained inside its own workspace.

[stevenj]

Summary

Make the way flutter projects are organized uniform with the rust backend.

Description

At the moment, Flutter code is in multiple places in the repo, and that means that flutter specific files are present in the root of the repo. In contrast to rust, where we contain all rust code and workspace configuration to the catalyst-gateway rust workspace.

It is subjectively cleaner and easier to maintain and reason through if workspaces do not contain nested unrelated workspaces. For example, currently, the rust workspace is a child of the flutter workspace and someone new to the project could think that melos.yaml applies to the catalyst-gateway rust project in some way. Yet as they have no actual parent/child relationship, this is not true, but the repo organization does not make this apparent.

With Catalyst Forge, this will also allow the flutter workspace/projects to have a different configuration to the rust workspace in CI. This is also important in future automation, because we will categorically be able to detect that changes under catalyst_voices were specifically related to the front end. At the moment this could only be determined from a growing? set of potential sources, and changes to the root Earthfile or root blueprint.cue would not be able to be identified as changes to the front end, even if they were, as they contain repo wide settings now, which effect all sub projects, not just the front end.

The aim is to make a single flutter workspace off the root of the repo, and move any flutter config files from the root to this workspace, as well as all flutter projects moved to that single workspace.

One possible suggestion:

Move everything inside a catalyst_voices workspace.

* repo root/
  * catalyst_voices/
    * Earthfile (Flutter project specific targets extracted from Earthfile in the repo root).
    * blueprint.cue (Configured specifically for the flutter workspace)
    * melos.yaml
    * pubspec.*
    * app/* (renamed from current catalyst_voices directory and moved one level down)
    * packages/* (renamed from current catalyst_voices_packages directory and moved one level down)
    * scripts/* (moved from root)
    * utilities/
      * remote_widgets/* (renamed and moved from utilities/catalyst_voices-remote_widgets)
      * poc_local_storage/* (moved from utilities/poc_local_storage)

This structure creates a unified single flutter workspace and removes redundant catalyst_voices attached to a number of directories.

[stevenj]

For Reference: Another Open-source monorepo which places the flutter workspace in its own sub-directory off the main repository root is at https://github.com/growerp/growerp/tree/master

[jmgilman]

The underlying assumption of Forge is that each repository has one or more "projects" that are nested within the repository at dedicated paths. The root blueprint.cue is only supposed to be for global configuration. I agree that we should avoid having any project-specific settings and/or configuration in the root of the repository.

If this is non-standard for Flutter then that seems to make it hostile to polylingual mono-repo's. It doesn't appear to be a hard limitation, though, as demonstrated by the example repo given by Steven. In this instance, for sake of consistency, we need to embrace a non-standard approach for this one particular ecosystem.

[stevenj]

Confirmed with melos developers via discord that no functionality will be lost. It will have the same limitation as cargo, must be run from inside the flutter workspace directory, and not the repo root.

[dtscalac]

One minor issue is with IDE integration. /.vscode/launch.json currently contains catalyst_voices specific configurations. If catalyst_voices would be self-contained then we need to move .vscode config there too. Generally, front-end devs working on catalyst_voices would treat /catalyst_voices as their root workspace, thus any configuration which is in the monorepo's root would be ignored.

Potential issue with this approach is that if an engineer wanted to interact (i.e. via VSCode plugin) with any earthly targets specified in the root Earthfile (such as check-spelling or check-markdown), they need to change the workspace in VScode. Running the earthly targets from command-line will still work, you can always change directory to the parent.