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

[tolmasky]

So, a frustration I've always had with 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. The idea is relatively simple, it is just a generalization of inline-environment-variables, except you explicitly pass object structures, like this:

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.

[nbkhope]

I have a Nodejs script that takes a JavaScript file and transpiles it using Babel. Is it possible to pass the value of Nodejs variables into the generated code?

It would be like injecting values from Nodejs in place of a placeholder in the transpiled code. I couldn't find a way to do it, so perhaps your feature would allow me to do it.

[tolmasky]

Hi @nbkhope,

I think this largely depends on the type of javascript value being passed in. If it is a simple JSON-style value, it should indeed work. That being said, we hired @nicolo-ribaudo to implement templating in Babel, which you might also be interested in. The key difference is that this script is like an "optimization", that can find global variables and inline values. The templating feature is designed to create JavaScript "templates" (that would not compile on their own), and inline values there.

I will point out that the current code has an easily fixable bug where only strings and booleans are supported. This is a result of originally being intended specifically for environment variables, but I believe there is no reason to keep this restriction, and the fix is a one liner though that I'd be happy to do if you decide you want to use this. Here is a quick example:

https://runkit.com/tolmasky/replace-global-member-expressions-example