Thanks for the feedback @noahtallen!

I'm not convinced about having post-install run twice for each environment.

To be fair, you're only running it twice if you use the top-level configuration option:

• If you wanted to use a single script and have some special handling, you can use the WP_ENV_POST_INSTALL_ENVIRONMENT environment variable in your script pretty easily. They can also use the same variable to run the same commands on each environment if they want. Lots of choices!
• You can alternatively use the environment-specific configuration to run it in a single environment. No need for any other complication.

As it stands, Gutenberg's own tests environment contains a significant number of plugins that the development environment does not. It feels aligned with that principle to have a separate postInstall file that addresses any concerns E2E tests may have.

I like the flexibility that this provides when treated like the rest of the configuration options. It would feel strange if this was the only .wp-env.json option that behaved this way. Would this be acceptable if it was documented and we switched out the examples for an environment-specific one against tests? That would push people towards their most-likely use-case while still providing that flexibility without more complication around options and commands.

A side note is whether there could be race conditions using execSync on the same file at the same

Depending on what the script is doing, this may be true. I would wager that most scripts aren't going to be doing anything contentious, since at worst, they would be doing the same thing. Given that the script is supposed to be written with multiple executions in mind, there shouldn't be issues.

Good points. What stands out to me with this option is that it's not actually unique to the environment, which is very different from the other options. For example, when I set the port or WordPress version, those are by definition unique to that environment. It can't possibly change something in the other environment. But with this script, you can do whatever you want! To me, that makes it less of an environment-specific thing, and more of a wp-env-tooling-specific thing. (E.g. "execute this code at this part of the lifecycle")

To me, having an environment level option implies that it will only do something to that environment. But you could easily write your development script to update tests, and your tests script to update development. (Not that that's really a problem -- but to me, that's why it feels different from the other options)

It just makes me wonder what having the environment-level option actually enables users to do:

# Pseodocode for script executed twice:
cmd="wp foo"
if ( WP_ENV_POST_INSTALL_ENVIRONMENT == 'tests' ) {
  npx wp-env tests-cli "$cmd"
} else {
  npx wp-env cli "$cmd"
}

# Script executed once:
cmd="wp foo"
npx wp-env tests-cli "$cmd"
npx wp-env cli "$cmd"

I think I see the value of specifying different scripts (especially for inline values) in the environment configs. But I still don't love that putting it in the root configuration executes it twice. I think folks won't expect that

My biggest concern here is consistency @noahtallen, but, I think you might be right. When you set a top-level "core", for example, it is singular conceptually because it's set once (but in both containers). It's possible that, on that principle, it might make sense to only run it a single time.

I acquiesce :)

I took a look at implementing this as a top-level option only and it seems like there's going to need to be a refactor of the config parsing and validating to accommodate. Once that's done I'll revisit this!

Now that the config refactor has landed I'm closing this in favor of #50196. This PR is not really actionable anymore, and given the change in scope (from environment-specific to root), it makes sense to just close it.