How to merge ID and reporter code?

[rmx90210]

One of the goals of this repo is to create a single home for the grants ID and reporter code bases, since they will one day be a single web app. (Quick reminder: we are starting with centralizing the ID tool, and merging in reporter at a later date). This is thread for thinking about how we can structure the new repo and carry out the merge.

Merge strategies

Naive merge (not recommended)

The simplest merge would be to copy the cares-grant-opportunities and cares-reporter repos into their own top-level directory in this repo. Simplified to show architecture, this would look something like:

grants-tools
├── package.json
├── id
│   ├── package.json
│   ├── client
│   │   └── package.json
│   └── server
│       └── package.json
└── arpa-reporter
    ├── package.json
    └── src
        ├── server
        └── <client code lives at this level>

PRO

• Straightforward copy/paste of existing code (preserving Git histories aside)

CON

• We would still have two clients and two servers, and would need to write some code to stitch them together (potentially another child package?)
• There would be duplicated code, for user management, especially
  • Could pull this out into a common package?
• This seems like a lot of npm packages to wrangle (5-7) without a strong justification
  • They aren't reusable code
  • Their dependencies are largely the same if you slice by front vs. back end

Refactor + merge (recommended)

It may be more manageable long-term to refactor first, merging ID and reporter along the axis of client vs. server at the top level (reporter would just be stubbed out until we're ready to bring it over):

grants-tools
├── package.json
├── client
│   ├── package.json
│   └── src
│       ├── app
│       ├── id
│       └── arpa-reporter
└── server
    ├── package.json
    ├── app
    ├── id
    └── arpa-reporter

A few notes on this:

1. The app directories contain the code that wraps ID and reporter into a single app (think of app as the entry point, and importing things from id and reporter).
2. client has a src directory because its code gets transpiled before deploying, while the code in server is run directly—so there's less of a notion of "source" code.

PRO

• Leaner project structure
• Fewer npm packages
• More aligned with merging the two tools into a single product
• Dedupes code

CON

• More involved than naive merge

---

Preserving Git histories

It would be nice to preserve the Git histories of these projects, if feasible and not super time-consuming. Some tips via @alexallain, from a former project:

git filter-branch to rename everything into distinct submodules; and then used git fetch to import each complete history tree into the same repo, and git merge to merge them together

git doesn’t require that there be a unique root commit in a given repo, so you can use merge to stitch multiple dags together

---

This is just a proposal and would love to get your thoughts/perspectives @cmroberts @Mr0grog 👋

[rmx90210]

A few notes from chatting with @cmroberts:

• Let's go with refactor + merge above
  • RM: realizing this is a kind of a misnomer; it's more "scaffold out long-term project, then migrate code over"
• Anti-goal 1: merging ARPA reporter over to this repo
  • Instead, iterative feature development!
• Anti-goal 2: preserving Git history if it's impeding work on this repo