Port DNX "scripts" concept

[analogrelay]

DNX has a useful scripts construct where scripts can be assigned to run during certain lifecycle events in the dnu build/pack/restore pipelines. We should migrate that concept to dotnet. It is extremely useful for things like incremental compilation of dotnet itself where compiling an individual project can copy the resulting binary into your previous full build so that you don't have to rebuild the whole stack.

It works by adding a scripts section of the following form:

{
    "scripts": {
        "precompile": [ "echo Script 1", "echo Script 2", ... ]
        ...
    }
}

On each event, the scripts in the array are executed in sequence. The scripts can also contain variable replacements in the CMD format (%variable%; this syntax is used even on Unix, since we do the replacement before passing to the shell). Available variables depend on the script, but some examples include %project:ProjectDirectory% which gives the absolute file system path of the project and %compile:TargetFramework% or %compile:Configuration% which give the full framework name and configuration (respectively) currently being compiled.

Events include:

• precompile: Run after generating the RSP file, and provided the RSP file for potential modification
• postcompile: Run after the compiler, and provided the path to the output managed binary
• prepack: Run before packing compiled output into a nuget package
• postpack: Run after packing output into a nuget package and provided the path to the output package
• prerestore: Run before dotnet restore/nuget restore
• postrestore: Run after dotnet restore/nuget restore (often used to tie in other package managers like npm and bower)

/cc @davidfowl

[davidfowl]

I had an even crazier idea last night.

dotnet command runs

dotnet-command

Which will run the script pre{command}, dotnet-{command}, post{command}. Might not work well in all scenarios as context is required. But it's worth thinking about.

[analogrelay]

Yeah... I think that's getting a little more complicated that we want though. Worth thinking about

[TheRealPiotrP]

I like it. Code will be simpler and project.json will be easier to parse by humans. Having 4 top-level nodes [compile, pack, restore, publish] is much easier to reason about than 8.

[TheRealPiotrP]

@Sridhar-MS, I think you were starting to look at this issue as well.

[analogrelay]

@piotrpMSFT There would still be pre and post events in project.json in @davidfowl's proposal. He's just proposing a significantly more general solution of adding pre/post scripts to any dotnet command. For example, I could have a precompile-csc command or a preresgen command or a prerepl(?? I think it actually only makes sense for commands that have a project context) script.

[analogrelay]

Let's take expansion of this behavior offline or to a new thread though. I've submitted a PR to add the infrastructure and precompile/postcompile events. From there we just need to add the other events. I'll file bugs for those.

[TheRealPiotrP]

@anurse yep, I understand the proposal. Though it's more text, I think grouping pre/post scripts around their commands makes the overall experience easier to understand.

[Sridhar-MS]

I agree with @piotrpMSFT but I guess it will involve changing the project.json schema.

[analogrelay]

So are you talking about a possible restructuring of the schema? Something like

{
    "scripts": {
        "compile": {
            "before": [ ... ],
            "after": [ ... ]
        },
        ...
    }
}

If we're going to do that, maybe we change the top-level property name. Thoughts @davidfowl ?

[TheRealPiotrP]

right.

[analogrelay]

Ok, I'll let this issue represent the initial port of the code and the precompile event (I still think there's value in adding that as-is, even if we change it later). I'll open an issue to generalize this and we can start on that immediately after. IMHO it's easier to get the initial stuff in and generalize

[TheRealPiotrP]

agreed.