The current meaning of {env2.compatibleEnvironements = [env1] with target1 building in env1 and target2 building in env2} is that any file target1 and its output dependencies in env1 have to exists in env2 to allow target2 to build.

This problem can be solved by either:

• do a complete copy of env1 into env2.
  This is probably slow, but very easy to implement.
• if we know the list of files we output in env1 for target1 and its dependencies, only copy/symlink those files.
• do a complete build of target1 and its dependencies in env2 (probably the slowest version even if this one support incremental build to some extends).
• change the spec a bit, by making exported envs relative to the workspace and not the environment.
  Probably the most easy way to do it, but with probable corner cases.

It's very common to be able to "run" some commands after building things (or even to build things).

A run sequence is a target and its role is to execute a list of commands.
Bec
This attribute would prevent a target from being in the graph by default (ie: you need to ask the buildsystem to build this target).

"build envs=": { is: "group", elements: [
  { is: "environment", name: "local" },
  { is: "environment", name: "travis", tags: ["ci"] },
  { is: "environment", name: "gitlab", tags: ["ci"] },
  { is: "environment", name: "appveyor", tags: ["ci"] },
]},
"build msbuildsystem=": { is: "target", type: "run-sequence", 
  manual: true, // force explicit requirement of the target
  environments: "=build envs",
  sequenceByEnvironment: {
    "=?  ci": ["=install", "=build", "=test", "=coverage", "=tocoveralls"]
    "=build env:local": [  "=build", "=test", "=coverage", "=tohtml"     ]
  },
  "install=": { is: "group", elements: [
    { is: "component", cmd: "npm install -q -g @openmicrostep/msbuildsystem.cli@^0.4.0" },
    { is: "component", cmd: "msbuildsystem modules install @openmicrostep/msbuildsystem.js.typescript@^0.4.0" },
  ]},
  "build=": { is: "group", elements: [
    { is: "component", cmd: "msbuildsystem build -p @msbuildsystem -w dist/1/" },
    { is: "component", cmd: "node dist/1/node/node_modules/@openmicrostep/msbuildsystem.cli/index.js build -p @msbuildsystem -w dist/2/" },
    { is: "component", cmd: "node dist/2/node/node_modules/@openmicrostep/msbuildsystem.cli/index.js build -p @msbuildsystem -w dist/3/" },
  ]},
  "test="       : { is: "component", cmd: `mstests -c -t 20000 ${tests}` },
  "coverage="   : { is: "component", cmd: `istanbul cover mstests --report json -x 'msbuildsystem.*.tests/**' --root dist/3/node/node_modules/@openmicrostep/ -- -c -t 20000 -i -g perf ${tests}` },
  "tohtml="     : { is: "component", cmd: " cat ./coverage/coverage-final.json | remap-istanbul --output coverage --type html" },
  "tocoveralls=": { is: "component", cmd: "cat ./coverage/coverage-final.json | remap-istanbul --type lcovonly | coveralls" },
}

msbuildsystem build --target 'build msbuildsystem' --env travis

Recently we introduced a new associate element and changed the way object attribute were resolved to use the power of components.

The current spec is:

• associate behave like a component but has an elements attributes that hold a list of element to associate with other attributes (even those of the component tree).
• a target define an attribute as a component or an associate list
• an attribute that require a component is set with attribute: [component, ...], as this allow easy injection by target components of the final value, but prevent the target to set its own value.

The problem is: a target cannot overwrite the list of components that will compose the final value.
In general: any list cannot be overwritten by the target.

npm 5 changed the way npm works and thus current npm tricks fail in some cases (incremental npm install for example)