Skip to content
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

Open
wesleytodd opened this issue Sep 8, 2020 · 6 comments
Open

Overall Design for Project #7

wesleytodd opened this issue Sep 8, 2020 · 6 comments

Comments

@wesleytodd
Copy link
Member

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.

create-diagram-export

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!

@wesleytodd
Copy link
Member Author

Also, TBQH, I think there might be value in adding even one more level to this in-between create-pkg and the "low level generators" which would be create-base-package or 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
Copy link

boneskull commented 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-gitignore should create a .gitignore file. But should it decide what's in that file? Or are you suggesting that create-base-package would contain the content (the opinion) and just be composed w/ create-gitignore via create-git?

(In the instance of create-gitignore/create-git, I don't understand the proposed hierarchy. Could it be flat instead--create-git and create-gitignore being children of create-base-package? a .gitignore file is useless without an initialized repo, but not vice-versa.)

@wesleytodd
Copy link
Member Author

should it decide what's in that file?

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.

create-base-package would contain the content (the opinion) and just be composed w/ create-gitignore via create-git?

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).

Could it be flat instead--create-git and create-gitignore being children of create-base-package?

Yeah totally, I actually only broke them out because I don't own the create-git package and so had to publish my original examples as create-gitignore, so scoped it to that. In reality I think we could just build it all as part of create-base-package to 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
Copy link

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
Copy link
Member Author

For sure! I have a scattering of meetings, but I think Wednesday and Friday are my best days. Let me know what works!

@boneskull
Copy link

@wesleytodd either works for me, pretty open. not sure what TZ yr in but I’m in WA state

@thescientist13 thescientist13 pinned this issue Jul 29, 2021
@jonchurch jonchurch changed the title How to decompose the individual domains of this work START HERE - Design Overview Jul 29, 2021
@wesleytodd wesleytodd changed the title START HERE - Design Overview Overall Design for Project Jul 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants