--globals option

[zindel]

Some modules account for certain global variables to exist at runtime. The most known examples are global and process. This option would permit to specify the JavaScript file to populate all the global variables bundle may need. It will be included at very top of the bundle.

By default the value included would be:

global = window;
process = { env: {NODE_ENV: "<mode>"}};

Thoughts?

[thangngoc89]

@zindel the process.env.Node_env is a special case. Bundler like webpack and browsify usually replace them inline for dead code elimination

[zindel]

@thangngoc89 we're replacing process.env.NODE_ENV as well. Some modules account on existence of the process and/or process.env though. Maybe, we can omit the NODE_ENV part...

[thangngoc89]

@zindel then I think this is a reasonable approach

[boyswan]

Is there currently any way to set environment variables through fpack?

[bloodyowl]

would automatically replacing process.env.X by the available environment variable at build time be considerable?

[zindel]

@boyswan not at the moment. What is the use-case for them (except for NODE_ENV)?

@bloodyowl I am reluctant to add this functionality in this specific form since it breaks the predictability of the build. I.e. now we only consider the files & command line options as inputs. Adding environment variables will create the third "hidden" input source. Actually, the same question as above: what is the use-case for them?

[TrySound]

I use --mock flag to set configs with necessary options. Globals are always bad for isolation. process.env.NODE_ENV should be enough.

[bloodyowl]

@zindel the use case is often to pass flags (such as NODE_ENV) and environment information (such as API_URL) without having to write a special command for each environment.