You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, CLI handling is done exclusively in Main.
Library authors which depend on happy packages would however benefit from a model where the CLI handling is also distributed to the packages which use the CLI flags.
An option would be to create an additional -cli package for each currently existing happy package. For example, the happy-frontend-cli package would then contain the CLI flags and the CLI handling that is relevant for the happy-frontend package.
All logic which is currently held in Main would be split into these -cli packages, and Main would just stitch these separate CLI stubs together in a sensible way.
This would enable library authors to exchange happy package components without having to copy and adapt the whole Main file.
I'd be happy to work on an implementation if desired.
The text was updated successfully, but these errors were encountered:
@knothed would you still say that a CLI package is absolutely necessary?
I don't think we'll see it for happy 2.0. But extracting one more subcomponent is not really a breaking change, so it would be realistic for happy 2.1 (say).
No, I don’t think it’s necessary.
In happy-rad for example I now only support RAD so there is not much code duplication of happy’s main file. So it depends on what users of happy-lib want, which we don’t know yet.
Currently, CLI handling is done exclusively in Main.
Library authors which depend on happy packages would however benefit from a model where the CLI handling is also distributed to the packages which use the CLI flags.
An option would be to create an additional
-cli
package for each currently existing happy package. For example, thehappy-frontend-cli
package would then contain the CLI flags and the CLI handling that is relevant for thehappy-frontend
package.All logic which is currently held in Main would be split into these
-cli
packages, and Main would just stitch these separate CLI stubs together in a sensible way.This would enable library authors to exchange happy package components without having to copy and adapt the whole Main file.
I'd be happy to work on an implementation if desired.
The text was updated successfully, but these errors were encountered: