Feature: Support arbitrary pre* and post* scripts

[coopy]

Feature Request

npm supports defining scripts starting with pre and post to be run before and after the named script. E.g. you can define predev which would be run prior to running dev. This is a very useful lifecycle hook, and a use case for it is to generate an Ecology docs index.html from static-index.jsx prior to starting up builder run docs-dev|docs-hot (FormidableLabs/victory-component-boilerplate#20).

From the npm docs:

Additionally, arbitrary scripts can be executed by running [npm run myscript]. Pre and post commands with matching names will be run for those as well (e.g. premyscript, myscript, postmyscript).

Tasks

• Implement pre<task>, post<task>.
• Each implied task must be successful for next to execute.
• Only pass -- --FLAG to main task like npm
• Document features + gotchas.

Notes

  "scripts": {
    "prepretemp": "echo PREPRE",
    "postpretemp": "echo POSTPRE",
    
    "pretemp": "echo PRE",
    "temp": "echo TEMP",
    "posttemp": "echo POST",

    "preposttemp": "echo PREPOST",
    "postposttemp": "echo POSTPOST",
  }

Note: A -- passed flag only attaches to <task>, not pre or post for both npm and yarn

$ npm run temp -- --hi

> builder@3.2.3 pretemp /Users/rye/scm/fmd/builder
> echo PRE

PRE

> builder@3.2.3 temp /Users/rye/scm/fmd/builder
> echo TEMP "--hi"

TEMP --hi

> builder@3.2.3 posttemp /Users/rye/scm/fmd/builder
> echo POST

POST

$ yarn run temp -- --hi
$ echo PRE
PRE
$ echo TEMP --hi
TEMP --hi
$ echo POST
POST

Note - npm: If running a pre<task> command directly, a prepre<task> or postpre<task> will not run.

$ npm run pretemp

> builder@3.2.3 pretemp /Users/rye/scm/fmd/builder
> echo PRE

PRE

$ npm run posttemp

> builder@3.2.3 posttemp /Users/rye/scm/fmd/builder
> echo POST

POST

Note - yarn: If running a pre<task> command directly, a prepre<task> or postpre<task> will run, unlike npm

$ yarn run pretemp
yarn run v1.3.2
$ echo PREPRE
PREPRE
$ echo PRE
PRE
$ echo POSTPRE
POSTPRE

$ yarn run posttemp
yarn run v1.3.2
$ echo PREPOST
PREPOST
$ echo POST
POST
$ echo POSTPOST
POSTPOST

[ryan-roemer]

@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!

[coopy]

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.

[ryan-roemer]

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

[jstrimpel]

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

[ryan-roemer]

@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.

[jstrimpel]

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

[ryan-roemer]

@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!

[jstrimpel]

@ryan-roemer Makes sense to me.

[ryan-roemer]

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...

[ryan-roemer]

Implemented in #156