Split this package up in a set of modular packages

[WyriHaximus]

This toot got my thinking: https://toot-toot.wyrihaxim.us/@[email protected]/111439133427970079

This package is current playing several roles:

• The client generator
• Spec parser and putting it into an easier to use representation
• Generates webhook parses for a REST client ????

By splitting it up into the following packages:

• Generator
• Representation layer
• Spec parser
• WebHook PSR-15 middleware generator
• REST Client generator

And give the generator a pluggable design so that you can mix and match what you need. Maybe even generator the GitHub REST client and the PSR-15 WebHook middleware in one go for two separate packages. Or just the Schema classes without any specific object hydrator preferences in them. Parts of this can already be done. Yanking out the Representation layer is quick and easy, so is the spec parser. But building a modular pluggable generator is going to be the harder part and I need more then just my personal requirements for it. Any feed back on this is appreciated!

[Ocramius]

TBH, the atomic purpose I needed for my cases was about generating client DTOs.

I don't mind dragging on all dependencies, since this tooling is only used at build time, but the current difficulty with using this library comes with identifying the installation method and entry point.

I suggest splitting out the runtime part only, which has to be dragged into production code too.

[WyriHaximus]

TBH, the atomic purpose I needed for my cases was about generating client DTOs.

I don't mind dragging on all dependencies, since this tooling is only used at build time, but the current difficulty with using this library comes with identifying the installation method and entry point.

I suggest splitting out the runtime part only, which has to be dragged into production code too.

Maybe I should have split this up into two issues. One for splitting up the packages, and another one to make the generator more configurable to your needs. Because with the latter you could configure it to only generate the DTO's. It would become a completely different package, but IMHO it's the right long term direction.

but the current difficulty with using this library comes with identifying the installation method and entry point

Yes I really need to improve that, another part would be all the packages the generated code requires.