We have already discussed Command Line Arguments in ElectronJS. Command-line arguments are important because they can be used to control the behaviour of the application. We can pass Command-line arguments to Electron from outside the application while launching or we can simply hard code these values within the application. Environment Variables in Electron also control the application configuration and behaviour without changing the code. Some specific behaviours in Electron are controlled by environment variables rather than command-line arguments because they are initialized earlier than the command-line flags and the application’s main function code. In this tutorial, we will look at the different environment variables used by Electron and their respective classifications.
We assume that you are familiar with the prerequisites as covered in the above-mentioned link. For Electron to work, node and npm need to be pre-installed in the system.
As mentioned above, in case we are hardcoding command-line flags within the application, we need to import the CommandLine Property of the app Module, but we don’t need any additional code changes for setting environment variables in Electron. However, Since Electron also supports the global process object, we can set the environment variables via code as well. For example:
process.env.GOOGLE_API_KEY = 'YOUR_KEY_HERE'
For more details on the process object, follow Process Object in ElectronJS. There are two main kinds of Environment Variables provided by Electron:
- Development variables
- Production variables
Development Environment Variables as the name suggests, are intended primarily for development and debugging purposes within the application.
- ELECTRON_ENABLE_LOGGING: This environment variable is set to true, Prints Chromium’s internal logging to the console of the application.
- ELECTRON_LOG_ASAR_READS: When Electron reads from an ASAR file, if this environment variable is set to true, logs the read offset and filepath to the system tmpdir. The resulting file can be provided to the ASAR module to optimize file ordering which improves the performance of the Electron application and reduces the load on the system resources. An ASAR archive is a simple tar-like format that concatenates files into a single file. The electron can read arbitrary files from it without unpacking the whole file. This environment variable was introduced in the later versions of Electron.
- ELECTRON_ENABLE_STACK_DUMPING: This environment variable is set to true, then prints the error stack trace to the console when the Electron application crashes. This environment variable will not work if the crashReporter is started. crashReporter module in Electron is responsible for submitting crash reports to a remote server. For more details on the crashReporter module.
- ELECTRON_DEFAULT_ERROR_MODE: This environment variable is only supported in the Windows Operating System. This environment variable is set to true, shows the Windows’s OS crash dialog when the Electron application crashes. Just like ELECTRON_ENABLE_STACK_DUMPING, this environment variable will not work if the crashReporter is started.
- ELECTRON_OVERRIDE_DIST_PATH: When running the application from a packaged file in the development environment, this environment variable tells Electron to use the specified build of Electron instead of the one downloaded by npm install. This environment variable takes in a String filepath, where the specific build of Electron is stored on the native System. This is especially useful when we have made our own changes to the source code of the original downloaded Electron package.
Production Environment Variables as the name suggests, are intended primarily for use at runtime in a packaged Electron applications. These Environment variables are especially useful when deploying the packaged Electron application to a different server in a production environment.
- NODE_OPTIONS: Since Electron combines the NodeJS and Chromium into a Single runtime, Electron includes supports for a subset of NodeJS NODE_OPTIONS environment variables. The majority of options provided are supported in Electron with the exception of those which conflict with Chromium’s use of BoringSSL. BoringSSL is a fork of OpenSSL that is designed to meet Google’s needs. OpenSSL is a robust, commercial-grade, and full-featured toolkit for the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols in HTTP. It is also a general-purpose cryptography library.
We can provide multiple options to the NODE_OPTIONS environment variable. The Unsupported options are:
- GOOGLE_API_KEY: Many of Google’s services require an API_KEY to be generated for that particular project for that particular user for the services to be accessed from within the application. For example, Geolocation support in Electron requires the use of Google Cloud Platform’s geolocation webservice. To enable this feature, we need to acquire a Google API Key. This Key is usually Hardcoded within the Electron application and since this API key is included in every version of Electron for every valid session, it often exceeds its usage quota. To prevent this, we need to add the API Key as part of the environment. We can do so by placing the following code in the main process file, before opening any application windows or features that will make Google Services requests:
process.env.GOOGLE_API_KEY = 'YOUR_KEY_HERE'
- We can also set this environment variable from outside the application so that it is valid for every new Google Service requests session until it expires.
- ELECTRON_RUN_AS_NODE: This environment variable is set to true, Starts the Electron process as a normal NodeJS process.
- ELECTRON_NO_ASAR: This environment variable is set to true, disables ASAR support for the Electron application. This variable is only supported in forked child processes and spawned child processes that set ELECTRON_RUN_AS_NODE environment variable as well.
- ELECTRON_NO_ATTACH_CONSOLE: This Environment Variable is only supported in the Windows Operating System. This environment variable is set to true, doesn’t attach console logs to the current console session. Hence, no logs will be printed from within the application.
- ELECTRON_FORCE_WINDOW_MENU_BAR: This environment variable is only supported in the Linux Operating System. This environment variable is set to true, does not use the global menu bar on Linux platform for the Electron application.
- ELECTRON_TRASH: This environment variable is only supported in the Linux Operating System. This environment variable sets the trash implementation on Linux platform. Default value set for this environment variable is gio. It can hold the following values:
Apart from the Production and Development Environment variables, there are some variables which are set by Electron itself in the native System environment at runtime.
- ORIGINAL_XDG_CURRENT_DESKTOP: This variable is set to the value of XDG_CURRENT_DESKTOP that your application originally launched with. Electron sometimes modifies the value of XDG_CURRENT_DESKTOP to affect other logic within Chromium. So if we want access to the original value we should look up this environment variable instead. The XDG_CURRENT_DESKTOP environment variables inform you of what desktop environment is currently being used. This variable differs with different OS and different platforms. This variable is also used by other processes and applications apart from Electron and it is a System environment variable.
Example usage of Setting Environment Variables for Electron in
~$ set ELECTRON_ENABLE_LOGGING=true
~$ export ELECTRON_ENABLE_LOGGING=true
Note: These environment variables are reset and need to be set again every time we restart the computer. If we want to avoid doing so, we need to add these environment variables with their respective values to the .bashrc files. .bashrc is a shell script that Bash runs whenever it is started interactively. It initializes an interactive shell session. We can put any command in that file that we could type in the command prompt, and they will not be reset such as in this case, Electron’s environment variables.