Overall Design for Project

[wesleytodd]

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!

[wesleytodd]

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]

@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]

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]

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]

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

[boneskull]

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