Question about shared constants

We have the following code in shared constants:

const isDevEnv = process.env.NODE_ENV !== 'production';
const customerPortalTestUrl = 'TEST_URL'; 
const customerPortalProdUrl = 'PROD_URL';

export const STRIPE_CUSTOMER_PORTAL_LINK = isDevEnv
  ? customerPortalTestUrl
  : customerPortalProdUrl;

const isDevEnv = process.env.NODE_ENV !== 'production';
const customerPortalTestUrl = 'TEST_URL'; 
const customerPortalProdUrl = 'PROD_URL';

export const STRIPE_CUSTOMER_PORTAL_LINK = isDevEnv
  ? customerPortalTestUrl
  : customerPortalProdUrl;

When testing locally, I am seeing the file constants is fetched as it is, being able to see test url as well. Is this the expected behaviour? Is there any better way to be able to set these while keeping the test url hidden during the deploy?

3 Replies

kapa.ai•2d ago

Hi @mgp25. I'm kapa.ai, your friendly support bot. I will try to answer your question by searching through the knowledge base. :wave: ---------------------- Based on the information provided in the knowledge sources, I can offer some insights and suggestions regarding your question about shared constants in Wasp. The behavior you're observing is expected, but there are better ways to handle environment-specific variables in Wasp. Here's why and how you can improve it: 1. Client-side environment variables: In Wasp, client-side environment variables are embedded into the client code during the build process, making them public and readable by anyone. This is why you're able to see the test URL when testing locally Docs > Project > Env Variables (https://wasp-lang.dev/docs/project/env-vars). 2. Recommended approach: Instead of using shared constants, it's better to use environment variables for such configuration. For client-side variables in Wasp, you should use the REACT_APP_ prefix Docs > Project > Env Variables (https://wasp-lang.dev/docs/project/env-vars). 3. Separating development and production variables: You can create two separate files: .env.client for development and use environment variables for production Docs > Project > Env Variables > Defining Env Vars in Development (https://wasp-lang.dev/docs/project/env-vars#defining-env-vars-in-development). Here's how you could refactor your code: 1. In your .env.client file (for development):

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=TEST_URL

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=TEST_URL

2. In your client-side code:

export const STRIPE_CUSTOMER_PORTAL_LINK = import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

export const STRIPE_CUSTOMER_PORTAL_LINK = import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

3. For production, you would set the environment variable during the build process:

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=PROD_URL npm run build

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=PROD_URL npm run build

This approach allows you to keep your development URL separate from your production URL, and it won't be visible in the production build. Remember, client-side environment variables are always publicly readable, so don't put any secrets in them Docs > Project > Env Variables > Defining Env Vars in Production (https://wasp-lang.dev/docs/project/env-vars#defining-env-vars-in-production). If you're using wasp deploy fly deploy, you can set the production environment variable like this:

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=PROD_URL wasp deploy fly deploy

REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK=PROD_URL wasp deploy fly deploy

Discord support thread (https://discord.com/channels/686873244791210014/1220070515276775516) This approach should help you keep your test URL hidden during deployment while still allowing for easy configuration between environments. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @mgp25, I seem to be having a bit of trouble. Don't worry though, I've pinged my support and they will try to fix me up! :technologist: Perhaps try again in 15mins?

Vinny (@Wasp)•2d ago

Hey @mgp25 the bot gave a good suggestion here. Did it work? FYI, we've since updated Open SaaS code to use a better approach and refactored and improved the payments logic. You can check out the repo if you're curious: https://github.com/wasp-lang/open-saas/tree/main/template/app

mgp25OP•2d ago

Hello @Vinny (@Wasp) . Havent tried yet, but seems to be a good approach. We are on 0.13.0 we would need to check if there are backward breaks but we will look into it thank you! I am doing @kapa.ai :

export const STRIPE_CUSTOMER_PORTAL_LINK = import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

export const STRIPE_CUSTOMER_PORTAL_LINK = import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

But is getting TS2339: Property env does not exist on type ImportMeta I have tried other solutions based on vite-env.d.ts but causes :

XMLHttpRequest cannot load http://localhost:3001/auth/me due to access control checks.

XMLHttpRequest cannot load http://localhost:3001/auth/me due to access control checks.

because of vite misconfig probably. Any recommendation for this?

Gaming

Programming

Question about shared constants