Feature: Support arbitrary `pre*` and `post*` scripts about builder HOT 10 CLOSED

It would be great if this could make it into the next release. We have a bunch of scripts that && commands together. The last command is sometimes a notification, which we would like to move to a post, so that arguments can be passed to the last command in the chain of &&'s. In the example below the flag argument should make it to builder run baz, but if the builder run notify -- some notification message is &&'d onto multitask then baz will not receive the flag.

"multitask": "builder run foo && builder run bar && builder run baz",
"postmultiask": "builder run notify -- some notification message"

$ builder run multitask -- --flag

from builder.

@coopy -- Can you walk me through what the difference is with say:

$ npm run first && npm run the-main-thing && npm run after

?

Having magic pre|post script things may prove tricky to archetype developers and users when we merge tasks across project to archetype, so I'd love a solid example of what we can't do with composition in builder.

Thanks!

from builder.

Composition will certainly take care of my use case, since I can easily modify the archetype.

Composition will not help you if you wanted to add a pre or post behavior for an ARCHETYPE script in your PROJECT.

I guess the question is how far do we take the "just like npm" approach? For now, I'll close this.

from builder.

I guess the question is how far do we take the "just like npm" approach?

That is worth considering. Up to this point to manage complexity, we've been deliberately avoiding npm lifecycle special task names (like such we prefix with npm:). And, separately I'm trying to focus on the minimum viable feature set to support what we need, especially as we roll through a lot of bugs and real world use cases for our clients to support.

Happy to leave this one open in the icebox as the feature request itself is succinct and understandable. (Just the implementation, cross-project/archetype interaction, etc. issues have to be fully understood vs. the value add when we next reassess this feature).

from builder.

@jstrimpel -- I've added the ticket to our priority list for OSS work and will see if I personally have bandwidth to get it going next week. I've started rewriting the description of this issue to better reflect the work going into it.

from builder.

@ryan-roemer Awesome. Thanks. I can be a beta tester.

from builder.

@jstrimpel -- If you get a moment, can you peruse my WIP README updates of how I envision this feature working? (at https://github.com/FormidableLabs/builder/compare/feature/pre-post-lifecycle#diff-04c6e90faac2675aa89e2176d2eec7d8R383)

Specifically, while builder run <task> is straightforward, there are some behavioral choices to be made for builder concurrent <task1> <task2> and builder envs <task> with respect to pre|post.

Thanks!

from builder.

@ryan-roemer Makes sense to me.

from builder.

Status update: Didn't have a ton of time to work on this this week, but current progress is at https://github.com/FormidableLabs/builder/compare/feature/pre-post-lifecycle I think I've mostly planned out the complexities for things like --setup, concurrent, envs, etc. with new pre/post things.

I should be able to land this next week...

from builder.

Implemented in #156

from builder.