Any interest in replace-global-member-expressions (replace inline-environment variables)?

So, a frustration I've always had with [inline-environment-variables](https://github.com/babel/minify/tree/master/packages/babel-plugin-transform-inline-environment-variables), and tools that accomplish similar things, is the unintended unification of your current runtime's environment variables and the environment variables expected by the compiler's target environment. In other words, just because I am running the compiler in NODE_ENV="production" does not mean I want to compile for "production". In fact, several tools may work much slower by setting the actual environment variables to "development", solely to make sure your compiled replacements say "development". This applies even further for environment variables you expect to be around during the runtime of the compiled program but really make no sense to have floating around during compilation.

As such, we currently use a custom transform, "replace-global-member-expressions". You can view the source [here](https://github.com/babel/minify/tree/master/packages/babel-plugin-transform-inline-environment-variables). The idea is relatively simple, it is just a generalization of inline-environment-variables, except you explicitly pass object structures, like this:

```javascript
plugins: [["replace-global-member-expressions",
{
replacements:
{
process: { NODE_ENV: "development" }
}
}]]
```

One additional note is that it currently additional checks to make sure that the top key is a global in the current scope (so it won't replace it if you have `var process` in the scope for instance). If this is considered too much of a performance issue I am happy to either take it out or make it configurable.

You could of course construct `transform-inline-environment-variables` from `replace-global-member-expressions` if there was a desire to keep both for backwards compatibility reasons. Our current approach is to have the owning preset auto-fill it the current environment variables under certain conditions but also warn that the user should really be passing these in explicitly so as to not someday accidentally have an unintended consequence when choosing to set an unrelated environment variable during compilation. Again, I'd be happy with whatever thoughts with this as well.

Anyways, my basic question is whether you'd like me to submit this into this minify project.

Start by reading the existing babel-plugin-transform-inline-environment-variables implementation linked in the issue and compare its behavior with the proposed replace-global-member-expressions API. Decide how explicit replacements and the global-scope check should work, then identify the project’s expected tests and document what compatibility with the existing transform means for done.

Written by the indexing model from the issue text.