Why is wildcard import not supported?

[gabrieljoelc]

This line disallows me to doing this:

// config.js

import * as env from '@env';

export const firebaseConfig = {
  apiKey: env.FIREBASE_API_KEY
}

export const apiConfig = {
  endpointUrl: env.API_ENDPOINT_URL
};

This config objects allow me to scope config imports in my components. Wildcard support would allow the developer to specify the environment key name in 2 places (i.e. .env and in the config objects) instead of 3 (i.e. .env, import list, and in the config objects).

Is there a "best practice" reason I'm not aware of for this?

[goatandsheep]

This is the best practice because env can be very extensive. On a per-component basis, it's a lot of information that can couple the component to the project. If you want, you can abstract your dotenv as dotenv is really just supposed to be a way to help with enabling environment variables, not permeating config throughout your project.

[goatandsheep]

also realize that babel is processing these files. It is creating code that is generated and the program replaces the import with the values

[ebarahona]

This line disallows me to doing this:

// config.js

import * as env from '@env';

export const firebaseConfig = {
  apiKey: env.FIREBASE_API_KEY
}

export const apiConfig = {
  endpointUrl: env.API_ENDPOINT_URL
};

This config objects allow me to scope config imports in my components. Wildcard support would allow the developer to specify the environment key name in 2 places (i.e. .env and in the config objects) instead of 3 (i.e. .env, import list, and in the config objects).

Is there a "best practice" reason I'm not aware of for this?

Did you implement your own update to this? I'm also doing something similar:

// constants.js
// import { SOME_CONFIG_KEY as ENV_SOME_CONFIG_KEY } from '@env';  // this is a large list

import * as env from '@env';


// can be reversed
const SOME_CONFIG_KEY = (env.SOME_CONFIG_KEY) ?
   (env.SOME_CONFIG_KEY) :
   config.get('someConfigKey'); // config from remote config


export { ..., SOME_CONFIG_KEY }

[GollyJer]

Came looking for the same thing.
Our secrets are stored in the Expo cloud based build system. We aren't actually using a local .env file.

We are having to do things like this. Wildcard import would make this much cleaner.

note: SECRETS_ENV is set to "DEV" or "PROD".

import {
  DEV_FIREBASE_API_KEY,
  DEV_FIREBASE_APP_ID,
  DEV_FIREBASE_AUTH_DOMAIN,
  DEV_FIREBASE_MESSAGING_SENDER_ID,
  DEV_FIREBASE_PROJECT_ID,
  DEV_FIREBASE_STORAGE_BUCKET,
  PROD_FIREBASE_API_KEY,
  PROD_FIREBASE_APP_ID,
  PROD_FIREBASE_AUTH_DOMAIN,
  PROD_FIREBASE_MESSAGING_SENDER_ID,
  PROD_FIREBASE_PROJECT_ID,
  PROD_FIREBASE_STORAGE_BUCKET,
  SECRETS_ENV,
} from '@env';
import { initializeApp } from 'firebase/app';

const devConfig = {
  apiKey: DEV_FIREBASE_API_KEY,
  authDomain: DEV_FIREBASE_AUTH_DOMAIN,
  projectId: DEV_FIREBASE_PROJECT_ID,
  storageBucket: DEV_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: DEV_FIREBASE_MESSAGING_SENDER_ID,
  appId: DEV_FIREBASE_APP_ID,
};

const prodConfig = {
  apiKey: PROD_FIREBASE_API_KEY,
  authDomain: PROD_FIREBASE_AUTH_DOMAIN,
  projectId: PROD_FIREBASE_PROJECT_ID,
  storageBucket: PROD_FIREBASE_STORAGE_BUCKET,
  messagingSenderId: PROD_FIREBASE_MESSAGING_SENDER_ID,
  appId: PROD_FIREBASE_APP_ID,
};

const firebaseApp = initializeApp(SECRETS_ENV === 'DEV' ? devConfig : prodConfig);

export default firebaseApp;

Could look like this.

import * as env from '@env';
import { initializeApp } from 'firebase/app';

const config = {
  apiKey: env[`${env.SECRETS_ENV}_FIREBASE_API_KEY`],
  authDomain: env[`${env.SECRETS_ENV}_FIREBASE_AUTH_DOMAIN`],
  projectId: env[`${env.SECRETS_ENV}_FIREBASE_PROJECT_ID`],
  storageBucket: env[`${env.SECRETS_ENV}_FIREBASE_STORAGE_BUCKET`],
  messagingSenderId: env[`${env.SECRETS_ENV}_FIREBASE_MESSAGING_SENDER_ID`],
  appId: env[`${env.SECRETS_ENV}_FIREBASE_APP_ID`],
};

const firebaseApp = initializeApp(config);

export default firebaseApp;

[remitoffoli]

Same 👍