Environment Variables and Config in Parcel Quiz Quiz

Assess your understanding of handling environment variables and configuration files in modern build processes using Parcel. This quiz explores best practices, variable scoping, naming conventions, and secure configuration management for optimal project setup.

1. Environment Variable Exposure

   Which environment variable naming prefix is required for a value to be accessible in client-side code using Parcel?

   1. NODE_
   2. APP_
   3. PUBLIC_
   4. ENV_

   Explanation: The correct prefix is PUBLIC_, which tells the build process to expose the variable to client-side JavaScript. NODE_ is typically used for server-side environments and does not make variables available in client bundles. APP_ and ENV_ look similar to correct answers but are not recognized by default to enable variable exposure. Using the incorrect prefix may result in the variable not being injected at build time.

2. Securing Sensitive Configuration Data

   Why should sensitive data such as API keys be stored in a separate configuration file and not in source code when working with Parcel?

   1. Because configuration files are always faster to load
   2. Because build tools only read from configuration files
   3. To ensure secrets are not bundled and exposed to users
   4. To avoid syntax errors during the build process

   Explanation: Storing sensitive data in a separate, non-versioned config file ensures secrets are not accidentally exposed to anyone who receives the client bundle. Configuration files are not universally faster to load, and syntax errors relate to code validity rather than data storage. Build tools can read environment variables from many sources, not only configuration files, so that option is incorrect.

3. Importing Configuration in Source Files

   How can you safely reference an environment variable in a Parcel-built client-side JavaScript file?

   1. By using process.env.PUBLIC_MY_KEY
   2. By importing config.json directly
   3. By hardcoding the value in the file
   4. By referencing process.env.SECRET_KEY

   Explanation: Referencing an environment variable as process.env.PUBLIC_MY_KEY allows Parcel to replace it at build time with its value, provided it has the proper PUBLIC_ prefix. Importing config.json directly is not recommended unless it is designed for client-side use and free from secrets. Hardcoding values defeats the purpose of environment variables. process.env.SECRET_KEY lacks the required PUBLIC_ prefix, so it will not be injected.

4. Variable Expansion and Defaults

   If a required environment variable is missing from your .env file in Parcel, what is a recommended way to provide a fallback value?

   1. Set a default value in your source code with ||
   2. Rename the variable with a _DEFAULT suffix
   3. Leave the variable undefined for strict mode
   4. Add a comment in the .env file

   Explanation: Using the logical OR operator (||) in your code allows you to specify a default if the variable is missing, for example: process.env.PUBLIC_API_URL || 'https://default.url'. Adding comments or renaming the variable does not provide a fallback at runtime. Leaving variables undefined introduces errors rather than enforcing strictness.

5. Multiple Environments Management

   What is an effective method to handle different environment configurations (such as development and production) in a Parcel project?

   1. Maintain separate .env files for each environment and load the appropriate one
   2. Disable environment variables in production builds
   3. Only use global configuration with fixed values
   4. Repeat all variable declarations in every source file

   Explanation: Creating environment-specific files like .env.development and .env.production and ensuring the build process uses the correct one for each environment is a reliable technique for configuration management. Repeating variable declarations is inefficient and error-prone. Relying only on global configuration with fixed values removes flexibility. Disabling environment variables in production hinders proper configuration and is not recommended.