I’m fairly indifferent re: keeping the monorepo intact vs. splitting out the contracts & frontend into separate repos. As you folks mentioned, there’s clearly tradeoffs to each approach.
At this point in time, I personally like the developer experience of having everything in one repo & scripts that run the entire app. On the other hand, I agree that as the project continues to mature, the contracts will likely require fewer changes. Also if we intend to make this project easily forkable, in the long-term I could see value in decoupling the FE & e.g. having multiple FE templates, like one repo in React, one repo in Vue, given how opinionated individual teams can be about their FE stack.
This plan I do have concerns about. From my perspective, our FE repo was never intended to become the canonical clr.fund repo. We decided to fork the repo primarily because we knew we had specific requirements unique to our instance we plan to run (e.g. the assumption of a single funding round existing, tight control of the optimistic recipient registry flow, logic to send applicant data to a Google Spreadsheet for our team to review, pages & content specifically tailored to the Eth2 funding round). While we always intended to merge back features that the clr.fund community find useful (e.g. expanded recipient profile pages, cart features & round information UX improvements), we figured a wholesale adoption of our repo as the canonical app would likely not be in the best interest of clr.fund.
I’m open to how you folks want to move forward - if you’re set on this approach, I’m happy to bless your adoption of our code to be moved to the new FE repo. I just want to raise these considerations so we’re all aware.
From our perspective, the easiest approach would be to:
- our team continues to build off the Eth2 FE & repo
- we launch our funding round (current goal is September)
- afterwards, we merge back the useful generic features into the upstream clr.fund repo
I want to be cognizant of any blockers that may place on any other folks (e.g. if you’re waiting on specific features/components we’ve implemented), so please raise issues if you suspect that approach will slow you down in anyway or if you have any general concerns. Cheers.