-
-
Notifications
You must be signed in to change notification settings - Fork 77
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
About customization/extention of commands using "hooks" #52
Comments
Ps.: I have very diverging feeling on this kind of architecture I'm proposing. I just thought I should share the concept and what the benefits could be, if implemented ;) |
Yeah, this might be a useful feature, though I don't see real use cases so far ;-) |
I love the attention to modularity but I am curious what this might offer beyond what config options can achieve. If authors don't want to be bothered to add config, they might not want to be bothered to add hooks either, I'd think. For your ESLint/Babel use case, for example, the I think a bigger issue is just that the core tasks agree to be as granular as possible (as |
Also:
|
Here's one use case for hooks where I don't think options would work... For the While the default template would not be able to reference variables it couldn't know about in advance (unless providing a dumping ground where the order of insertion was arbitrary or perhaps task-suggested), this approach does allow for users to fully control the resulting order in the README by defining the template they desire. This may be more important, e.g., if one wishes npm/dependency badges in one place, testing/coverage badges in another place, etc. (e.g., Users might also take into account in template design that their templates might be reused with or without certain tasks, so there'd be no need to assume a variable's existence. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Project setup is a mess because one thing will always interferir with others: eslint my need to use babel's parsing; husky/lint-staged might need to understand there is prettier/eslint available; jest setup needs to know compilation decisions; and so on.
Taking that in consideration, and combining that with the (very nice) idea of presets
mrm
provides, I would like to suggest we could implement some sort of hook based capabilities for interactions between different tasks - or even global interference, eventually.One patter I think might suit the current architecture of this project is hooks - or event based alters, for that mater.
There are many parts of the system we could benefit from hooks. For instance, we could have hooks that allow altering formats actions, such as save on JSONs:
This would ultimately allow modules/tasks to alter results of JSON file editing (for whatever reason that be, this is just an example):
This, when combining with presets (that will ultimately run multiple tasks together) could mean lot's of decoupling on current code.
This could also allow, for instance, for specific packages (or even user's global setup) to extend specific action on tasks. #48, for instance, could be solved with something similar to this:
This could be very simply benefited anywhere, like a
mrm-task-yarn-workspace
package or the user's global, like this:I think if this gets considered, the implementation itself would definitely be retro-compatible, and could happen incrementally for most of the situations. Definitely there could be some code cleaning due to that, and some better separation of concerns in some packages, though that kind of refactor would have to be discussed in each particular case.
The text was updated successfully, but these errors were encountered: