Exploring what a mono-repo for core
libraries for PureScript would look like, how it would work, and what tradeoffs are made using this approach.
Merging all repos' code into one repo had 2 merge conflicts
ordered-collections
transformers
These both had to be fixed by hand by copying and pasting current master
content into repo since other folders were modified in the process.
There's three ways to do this. The first one is what this repo is currently doing:
-
One
ci.yml
file per repo (e.g. forarrays
it would bearrays.yml
). -
One
ci.yml
for the entire repo with one job for each reponame: CI jobs: arrays: # array build filterable: # filterable build etc: # ...
-
A hybrid approach. A few
ci.yml
files where the name indicates which repo's build is inside that file (e.g.a-e.yml
, which hasarrays
,effect
, etc. builds in it;f-l.yml
;m-r.yml
;s-z.yml
).
1 makes it easy to see the build for a specific repo, but spams the "All Workflows" view when changes are made to all repos at once.
2 makes spams the "run" view when changes are made to all repos at once. Moreover, we would be editing a very large file.
3 makes the best overall tradeoff by using a tree-like search.
GitHub does not allow one to subscribe to notifications based on what labels are added to an issue. One can either opt-in to the entire repo's notifications or none at all.
The best workaround I can think of is to use some GitHub Action to repost all conversation done in one issue to the corresponding PureScript repo and asking people to subscribe to that repo instead to get notified. The other alternative is to set up some service that notifies people separately. However, there entails a privacy concern.
Due to having all repos in one project, we would need repo-specific labels to indicate which project is affected by some bug. Moreover, the issue tracker could quickly become very large and discourage people from helping due to decision paralysis.