-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Overall Design for Project #7
Comments
Also, TBQH, I think there might be value in adding even one more level to this in-between 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. |
@wesleytodd I like this design so far. Can you help me understand the scope of the low-level generators? For example, (In the instance of |
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 |
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? |
For sure! I have a scattering of meetings, but I think Wednesday and Friday are my best days. Let me know what works! |
@wesleytodd either works for me, pretty open. not sure what TZ yr in but I’m in WA state |
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:
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 aREADME.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!
The text was updated successfully, but these errors were encountered: