Adding before/after lifecycle hooks

[shaine]

Loving this lib, finding it extremely useful in our project. As we accrue more and more scripts, we're finding that most scripts share some basic startup/shutdown behaviors, which (in line with the seeming intent of this lib) might be better served as some sort of lifecycle hooks rather than repeated boilerplate. As a trivial example, a big team might be interested in displaying a warning if a project's npm modules aren't up-to-date before running any script.

Following the convention-over-configuration style found here, scripty could look for ./scripts/hooks/before and ./scripts/hooks/after.

This seems appropriate to add to the lib to me, but I could also understand an argument that this is strictly a userland concern. Thoughts?

[searls]

I think this seems reasonable, but I'm not sure how/whether the lib needs to implement it, since your various scripts themselves could implement the same thing (depending on your scripting language you could make it invisible from each individual script, too).

That said, if you produced a simple PR that implemented an intelligent hooks/ directory (which got quashed gracefully in the presence of a conflicting package script named hooks:before), then I think that'd be cool. I imagine you'd want before-each, before-all, after-each, and after-all.

[texastoland]

👍🏽 I like this. What would be a use case for the *each variant? I think the best way to implement this would in options.

"scripty": {
  "prerun": "hooks:before",
  "postrun": "hooks:after"
}