About customization/extention of commands using "hooks" about mrm HOT 5 CLOSED

Yeah, this might be a useful feature, though I don't see real use cases so far ;-)

from mrm.

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 ;)

from mrm.

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 eslint task could check for babel config to determine whether to add the parser, and the babel task could of course consult its own config. Seems the lint-staged already checks for prettier.

I think a bigger issue is just that the core tasks agree to be as granular as possible (as lint-staged does). For a further improvement of this, I'd suggest readme only add a "Contributing" file, either if there is configFile set, or, if having the config file is desired by default, then allowing a noConfigFile: true option instead.

from mrm.

Also:

1. The docs should perhaps mention the idea of "namespacing" options, so as to avoid unintentional conflict with other task options.
2. I think a practice the built-in tasks might consider following is to expect explicit config more frequently but to merely log to console if the optional config is missing. Where it is really critical to a task, it could be required, e.g., readmeFile could be required for readme, but when not required, e.g., for the "ci" task optionally adding badges to the README, it would merely log the fact that no readmeFile was found so skipping that. Setting readmeFile to false would avoid such warnings entirely in ci (though not for tasks where it is required like readme). (I guess even the idea of required options could be dropped, such that the readme task could even be made to avoid erring under such conditions, making it easier to merge configs without needing to disable the task if not desired, but that might be confusing as to why a task was running but not having an effect.) But this raises the question too of whether let's say ci should have an option not to add to the README so that if one wanted a README and ci file, but not a CI badge, then one could do so. I think for built-in tests, the more configurable (though with reasonable defaults), the better.

from mrm.

Here's one use case for hooks where I don't think options would work...

For the readme task, other tasks might wish to advertise that they have some block to insert, such as a badge to reference, and provide the text value for such blocks. The readme task could then populate any template which referenced the registered additional variables.

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., ${npmBadge} ${testBadge} ${coverageBadge} ## Intro)

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.

from mrm.