Repository navigation
Overall Design for Project #7
Description
I have a proposal for how the various parts of this work can fit together. My goal with this is to put the ownership of domains in the right place, so that as we move forward this is not just one "monolith" generator project. I think if we as the Package Maintenance Team try to support something which does it all we will have taken too much on. So my goal is to leverage community work, as well as give a really clean way to interface up and down the dependency hierarchy.
As illustrated in this diagram, I see three distinct layers:
- low level generators
- this package
- userland opinionated wrappers
The idea is that things like modifying a package.json have a bunch of concerns which are not applicable to the task of writing out and updating a README.md file. If we design in such a way that those are not required to all be in the "package" scaffold, we can greatly simplify each component. The hard part then is how they interact with each other, the generator implementors and the end users.
Having spent some time on this problem, I do have a package I think solves this problem well without magic. The "without magic" is a part I highly value, and one which I think other approaches I have seen do not take. I can share it later assuming that folks don't totally disagree with my decomposition in the diagram.
All thoughts and feedback welcome!
Activity
wesleytodd commentedon Sep 8, 2020
Also, TBQH, I think there might be value in adding even one more level to this in-between
create-pkgand the "low level generators" which would becreate-base-packageor something. The goal being that the "opinions" are all centralized to one place.If I think about the volatility, the opinions layer and the userland generators are the most likely to change. The under layers are probably pretty stable once we knock them out well. So as a "volatility decomposition" goes, I think it aligns fairly well with this "functional decomposition", which is a good sign IMO.
boneskull commentedon Jan 5, 2021
@wesleytodd I like this design so far. Can you help me understand the scope of the low-level generators? For example,
create-gitignoreshould create a.gitignorefile. But should it decide what's in that file? Or are you suggesting thatcreate-base-packagewould contain the content (the opinion) and just be composed w/create-gitignoreviacreate-git?(In the instance of
create-gitignore/create-git, I don't understand the proposed hierarchy. Could it be flat instead--create-gitandcreate-gitignorebeing children ofcreate-base-package? a.gitignorefile is useless without an initialized repo, but not vice-versa.)wesleytodd commentedon Jan 5, 2021
I think that it should understand basic concepts of a gitignore and provide helpful defaults. The package as it is now allows you to pick from the JS-centric templates provided by github. I would think that if we (the PM team) has strong opinions we would figure out the best place for those in the code, which could be in the lower level packages, or in our base package.
Yes, this is exactly what I was thinking. The trouble I have seen with past generator ecosystems is they do not decompose well and thus as soon as you stray from the single well maintained path you are on your own. The design of this is to de-couple the parts likely to change (our opinions) from the foundational unchangeable truths (the format of gitignore in this case).
Yeah totally, I actually only broke them out because I don't own the
create-gitpackage and so had to publish my original examples ascreate-gitignore, so scoped it to that. In reality I think we could just build it all as part ofcreate-base-packageto start and only refactor things out as it makes sense. As long as we agree on the end architecture, how we get there should be what is most productive at the time.boneskull commentedon Jan 6, 2021
I think I would rather like to help with this than the github-user-org-copying tool. Do you think you might have 30m this week to chat about it?
wesleytodd commentedon Jan 6, 2021
For sure! I have a scattering of meetings, but I think Wednesday and Friday are my best days. Let me know what works!
boneskull commentedon Jan 6, 2021
@wesleytodd either works for me, pretty open. not sure what TZ yr in but I’m in WA state
[-]How to decompose the individual domains of this work[/-][+]START HERE - Design Overview[/+][-]START HERE - Design Overview[/-][+]Overall Design for Project[/+]