Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow env variables that are used to detect deployment environment for Nuxt #9860

Open
1 task done
MickL opened this issue Jan 31, 2025 · 17 comments
Open
1 task done
Assignees
Labels
good first issue Good for newcomers

Comments

@MickL
Copy link

MickL commented Jan 31, 2025

Verify canary release

  • I verified that the issue exists in the latest Turborepo canary release.

Which canary version will you have in your reproduction?

2.3.4

Description

At Nitro / Nuxt environment variables are used to automatically determine what deployment environment the build is in, and then using a specific build preset for that environment. This results in a zero configuration build: Deploying Nuxt or Nitro projects to whatever provider (Vercel, Cloudflare, Deno Deploy, etc. etc.) just works automatically.

Unfortunately this doesnt work anymore when Turborepo comes into play because Turborepo removes all env variables that are not set in the globalEnv array (if not using --env-mode=loose).

May it be possible that you dont remove all environment specific variables that are used to determine the build environment by default? You can find a full list of the variables Nitro / Nuxt is using here: https://github.com/unjs/std-env/blob/main/src/providers.ts#L59

Issue at Nitro: nitrojs/nitro#3051

@MickL MickL added kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage labels Jan 31, 2025
@anthonyshew
Copy link
Contributor

anthonyshew commented Feb 28, 2025

Happy to take any PRs that help with this!

@anthonyshew anthonyshew added good first issue Good for newcomers and removed kind: bug Something isn't working needs: triage New issues get this label. Remove it after triage labels Mar 9, 2025
@ogbird
Copy link

ogbird commented Mar 11, 2025

I'd like to take a crack at this, @anthonyshew. I'm still learning Rust so I might have some annoying, Fisher-Price tier questions. Are you available for a bit of pestering if it comes to it? Is here OK, or is there a better way to ping you without clogging up this issue?

@anthonyshew anthonyshew changed the title Allow env variables that are used to detect deployment environment Allow env variables that are used to detect deployment environment for Nuxt Mar 11, 2025
@anthonyshew
Copy link
Contributor

Sounds great! I believe it will look a lot like this PR: #8725

@ogbird
Copy link

ogbird commented Mar 13, 2025

So based on your PR link, @anthonyshew and your comments @MickL, this seems like we're just updating this frameworks.json file to include the Cloudflare Pages dependency? Are you working with Nitro or Nuxt or both @MickL?

@anthonyshew
Copy link
Contributor

Sounds correct from my end!

@MickL
Copy link
Author

MickL commented Mar 13, 2025

Adding CF_PAGES variable will only fix Cloudflare. Personally I would add all the variables used here to support detection of all environments, not just Cloudflare. Only then frameworks that deploy everywhere, like Nitro and Nuxt, can detect its environment.

This variables or not specific to Nuxt/Nitro but specific to environments. Other frameworks might want to use the same variables but cant find them because Turbo removes them.

@ogbird
Copy link

ogbird commented Mar 13, 2025

Ah, thanks @MickL, that link to those providers clicked for me now.

So as a quick confirmation based on that list of providers, you would expect:

CLOUDFLARE_PAGES -> Add CF_PAGES
BITBUCKET -> Add BITBUCKET_COMMIT
BUILDKITE -> Don't add anything

And that's in this UnJS repo, does that mean Nuxt and Nitro have UnJS as a dependency? Therefore, if we encounter a framework with UnJS, we could add a default set of wildcards?

@MickL
Copy link
Author

MickL commented Mar 13, 2025

Nitro is kinda a compilation of UnJS packages and kinda half of Nuxt is Nitro.

This looks good to me, lets have @pi0 confirm, he is the creator if most (all?) UnJS packages and Nitro.

@pi0
Copy link
Contributor

pi0 commented Mar 14, 2025

There is a canonical place we maintain a list of known provider environment variables: https://github.com/unjs/std-env/blob/main/src/providers.ts

If it would be useful to expose an array of known variable names for turbo repo we can definitely do that 👍🏼

@ogbird
Copy link

ogbird commented Mar 14, 2025

I don't think that would benefit this change, except in added clarity, @pi0. I'm thinking we should just keep it simple, add this provider list to the Nitro and Nuxt framework definitions we already have. I'll take a spin through the other frameworks listed and see if they have UnJS dependencies. Unless you think we should make this more dynamic @anthonyshew ?

@MickL
Copy link
Author

MickL commented Mar 14, 2025

This will not work very well if you add it only to Nitro. For example Nitro is using H3 server and H3 is using SrvX. So if one would be using Turbo + SrvX or Turbo + H3 it would mean this frameworks cant detect the environment where they are deployed to. And all other frameworks, outside of the UnJS ecosystem, too.

@anthonyshew anthonyshew self-assigned this Mar 15, 2025
@anthonyshew
Copy link
Contributor

Unless you think we should make this more dynamic @anthonyshew ?

Let's keep this hardcoded. Fetching at compile time would be some real complexity on our end that I'd rather not invite.

@pi0
Copy link
Contributor

pi0 commented Mar 15, 2025

Simple story:

Deployment providers have known env variables to be auto detected. (vercel, was actually one of the first pioneered this)

(any) code needs to automatically detect the current deployment providers needs access to this env variables.

Turborepo needs to enable known provider env variables in order to allow zero config deployment mechanism.

———-

Nitro / nitro based frameworks are zero config.

std-env maintains a list of the known env variables and we are constantly in contact with providers to keep them updated.

it is totally an implementation detail. Nothing about unjs (or h3, srvx) or using this specific package matters other than the fact you can reuse same source of info instead of maintaining same thing separately.

@anthonyshew
Copy link
Contributor

anthonyshew commented Mar 15, 2025

I'm not sure what you're meaning to say but just to make sure I'm clear: If someone in this thread would like to make support robust, please add the needed variables to our hardcoded list. We're not interested in changing the design at this time.

If someone would separately like to write a Discussion in the Ideas category for a larger change, that'd be great, too! But let's focus on getting the specific needs of this Issue addressed for now.

Thank you!

@pi0
Copy link
Contributor

pi0 commented Mar 15, 2025

@anthonyshew What list should be updated frameworks.json?

We need to add list of "platform environment variables" (standalone of frameworkworks) to nitro, nuxt, solidstart, (tanstackstart and analog are not present in json) and there would be more frameworks on top of nitro (and more env variables need to be updated in this list as more providers appear).

Is that acceptable for you?

@pi0
Copy link
Contributor

pi0 commented Mar 15, 2025

#10176

@ogbird
Copy link

ogbird commented Mar 15, 2025

Well, you beat me to it @pi0! Back to the good-first-issue list for me. Nice work everyone!

chris-olszewski pushed a commit that referenced this issue Mar 19, 2025
#9860

Deployment providers provide environmental variables to be detected.

[Nitro](https://nitro.build) uses this mechanism to auto-detect
deployment providers when building.

I have made a handcrafted list of some common items to nuxt and nitro
frameworks + `SERVER_*` (nitro supported env).

- aws_amplify: AWS_APP_ID
- azure_static: INPUT_AZURE_STATIC_WEB_APPS_API_TOKEN
- cleavr: CLEAVR
- cloudflare_pages: CF_PAGES
- firebase_app_hosting: FIREBASE_APP_HOSTING
- netlify: NETLIFY
- stormkit: STORMKIT
- vercel: NOW_BUILDER 
- zeabur: ZEABUR
- cleavr: CLEAVR
- render.com: RENDER



> [!IMPORTANT]
> This list will be most likely updated over time, meaning turborepo
support will be broken from time to time and need to manually be
updated. Nitro uses
[std-env](https://github.com/unjs/std-env/blob/main/src/providers.ts) as
source of this list.

> [!NOTE]
> Having list of provider envs under each framework, means that
turborepo does not supports platform envs for frameworks not explicitly
listed in this json (there are already few nitro based ones missing)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants