php-api-clients / openapi-client-generator

OpenAPI client generator
12 stars 2 forks source link

Split this package up in a set of modular packages #209

Open WyriHaximus opened 9 months ago

WyriHaximus commented 9 months ago

This toot got my thinking: https://toot-toot.wyrihaxim.us/@thepanz@phpc.social/111439133427970079

This package is current playing several roles:

By splitting it up into the following packages:

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 commented 9 months ago

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 commented 9 months ago

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.