This looks like a Turborepo issue and not a Turbopack one? TURBO_PLATFORM_ENV is a Turborepo feature. The naming is really confusing (our fault!), but Turbopack and Turborepo are entirely separate products.

Turbopack does perform static analysis of process.env and tries to replace those references at build time, but I don’t think Turborepo has anything like this. It is possible that your code is written in a way that evades Turbopack’s static analysis, but that wouldn’t have any impact on TURBO_PLATFORM_ENV, and I don’t think that’s the issue here.

causing these variables to be excluded from the TURBO_PLATFORM_ENV whitelist and unavailable at runtime

I’m not very familiar with Turborepo, but reading through https://turborepo.com/docs/crafting-your-repository/using-environment-variables#platform-environment-variables gives me the impression that TURBO_PLATFORM_ENV is just used for generating warnings if you forgot to declare an environment variable in your turbo.json, meaning that you still need to explicitly need to declare these environment variables there.

@bgw is one right track. Have you accounted for the variables in your env key of turbo.json? If you haven't they will be omitted from the task. More information in our docs: https://turborepo.com/docs/crafting-your-repository/using-environment-variables#strict-mode

Thank you both for your responses.

As a matter of fact, I did try a brand new deployment on Netlify and it worked right the way. So I am really suspecting an issue with the way Vercel is handling those environment variables.

As for reference here is my turbo.json file:

{ “$schema”: “https://turbo.build/schema.json”, “tasks”: { “build”: { “env”: [ “MY_CUSTOM_VAR_1”, “MY_CUSTOM_VAR_2”, “MY_CUSTOM_VAR_3” ] } } }

and so yes I did that..

Fabrice

Hello again,

After many hours of digging I found the culprit: there were 2 projects with the same name except the post fix : “myproject-gilt.vercel.app" and “myproject-tbma.vercel.app". The deployments were happening automatically on the 2.

The first one was having the good set of env variables and the second just a subset. When I was doing my manual testing I was using the wrong one (aka “tbma”) and all the different things we tried were of course not working.

So I finally understood that and now everything is working properly.

Now, that DOES NOT explain why the “tbma” project was there. I never ever created a second project.

I AM SUSPECTING it was automatically created when adding the Neon database support to the first project and I would encourage the Vercel folks to look at this issue as this is a terrible one that led me loose a full day of work.

Bye for now,

Fabrice

Thank you for coming back with worked for you!

Appreciate the feedback as well. Let us know if we can help with anything else for now