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?

14 Replies

kapa.ai•4w 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)•4w 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•4w 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?

Vinny (@Wasp)•4w ago

@kapa.ai export const STRIPE_CUSTOMER_PORTAL_LINK = import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK; gives the error TS2339: Property env does not exist on type ImportMeta

kapa.ai•4w ago

Let me check the knowledge base for you again. One moment! :books:

Vinny (@Wasp)•4w ago

did you resolve this yet?

kapa.ai•4w ago

---------------------- I understand you're encountering a TypeScript error when trying to access environment variables using import.meta.env. This is a known issue in Wasp, and I can provide some context and a workaround based on the information in our knowledge sources. The error you're seeing is related to TypeScript's type definitions for ImportMeta. This issue was discussed in a GitHub issue for Wasp Github Issue (closed): Ensure consistency between src/client/tsconfig.json and .wasp/out/react-app/src/tsconfig.json (https://github.com/wasp-lang/wasp/issues/1057). To resolve this error, you have a couple of options: 1. Use a type assertion to tell TypeScript that import.meta has an env property:

export const STRIPE_CUSTOMER_PORTAL_LINK = (import.meta as any).env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

export const STRIPE_CUSTOMER_PORTAL_LINK = (import.meta as any).env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK;

2. Alternatively, you can create a type declaration file (e.g., env.d.ts) in your src directory with the following content:

interface ImportMeta {
  env: {
    [key: string]: string | undefined;
  };
}

interface ImportMeta {
  env: {
    [key: string]: string | undefined;
  };
}

This will extend the ImportMeta interface to include the env property. It's worth noting that despite this TypeScript error, the code should still work correctly at runtime. The error is due to a discrepancy between the TypeScript configuration files used by your IDE and the ones used by Wasp for compilation. The Wasp team is aware of this issue and is working on ensuring consistency between the TypeScript configurations to provide a better developer experience Github Issue (closed): Ensure consistency between src/client/tsconfig.json and .wasp/out/react-app/src/tsconfig.json (https://github.com/wasp-lang/wasp/issues/1057). Remember, when using environment variables in Wasp, make sure to follow the guidelines for client-side env vars as mentioned in the Docs > Project > Env Variables (https://wasp-lang.dev/docs/project/env-vars), including the use of the REACT_APP_ prefix for client-side variables. ---------------------- Note: you can ask me a follow up question by @ mentioning me again :speech_balloon: ---------------------- Sorry @Vinny (@Wasp), 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)•4w ago

Hmm. I personally don't like this answer. Maybe @Filip has a better idea what might be causing this?

mgp25OP•4w ago

I did! I had to do some tweaking and also realised one thing along the way. 1. I had to create vite-env.d.ts which should has this inside:

/// <reference types="vite/client" />

/// <reference types="vite/client" />

2. /shared/constants.ts is a file that is run both in Client and server side, which means import.meta.env. wont work in server side, causing it to crash. So you end having two possible alternatives, either using a specific client side constants file, or just edit the shared constants to make sure is not run in server:

export const STRIPE_CUSTOMER_PORTAL_LINK = typeof window !== 'undefined'
  ? import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK
  : undefined;

export const STRIPE_CUSTOMER_PORTAL_LINK = typeof window !== 'undefined'
  ? import.meta.env.REACT_APP_STRIPE_CUSTOMER_PORTAL_LINK
  : undefined;

MEE6•4w ago

Wohooo @mgp25, you just became a Waspeteer level 1!

Vinny (@Wasp)•4w ago

ah number 2 makes sense. That was my first thought. You could also just 1. import it directly in the client files where it's being used (e.g. AccountPage.tsx, PricingPage.tsx) to 2. save the customer portal link as a server env variable and call it from the client (in a Wasp query), if that makes things easier.

mgp25OP•4w ago

I thought about 1. as well, but I wasnt sure which would be the best to have things organised. As per 2. I was about to ask how to do it, but just saw your edit, and making a query is also a suitable option. Will think about these Thank you for your response!

Filip•4w ago

Hey @mgp25, it seems to me like you are (or were) using an older version of Wasp and haven't fully migrated yet. For example, new Wasp projects come with vite-env.d.ts and creating it is covered in one of our migration guides (here) Anyway, are you maybe using an older version of Wasp (possibly older than 0.12)? If you migrated to the newer one, is it possible you missed a step from the migration guide? Thanks for sticking with us while we're in Beta and often publish breaking changes btw, we know it's a hassle 🙂

mgp25OP•4w ago

I am using wasp 0.13.0 but maybe I missed that step. Once I have everything working on my end will be migrating to the most recent wasp release. I have develop some software in the past and sometimes backward breaks are inevitable in order to make the code better/more efficient. Keep up the good work! 🙂

Gaming

Programming

Question about shared constants