Support custom-passthru env vars given as environment variable

[aviramha]

Goals

1. Make turborepo more robust, allowing more workflows to use it by allowing users to customize environment variables to passthrough in a way that is not dependant on calling Turbopack directly (i.e if using next can't add this currently, or if a different framework they'd need to be support it)

Background

Following #10984
I realized that the list is quite dynamic and keeps expanding, and there's already a way to allow - just harder to use when Turbopack is wrapped by other software.

Proposal

add TURBO_REPO_PASSTHRU_ENV environment variable that accepts colon separated environment variable names that will be passed through if detected.

Happy to contribute it!

[anthonyshew]

I'm not sure what's being asked for here.

• globalEnv does what's described, to allow passthroughs.
• I see mentions of Turbopack that I'm not sure what are about.

Is the request that users be able to modify for their own local environment without having to commit the changes to the repository? If so, this sounds like a design that wouldn't scale. In the ideal case, a repository always runs one way, with no need for developers to constantly customize to their liking. If we assume that to be true, letting developers passthrough environment variables at their whim doesn't seem like a happy path.

Still, the --env-mode=loose flag does exist as an escape hatch for this use case, anyway. If you truly must, you can let through more environment variables into tasks this way.

[aviramha]

Thanks for your response:

• globalEnv - it's not available when using next. i.e next dev --turbopack -p 4004 there's no way of passing environment variables
• the --env-mode=loose isn't available from next cli too, afaik

The use case is that we have users of mirrord that want to run their next/turbopack project using it. tl;dr what mirrord does is run your process in remote context - it loads into the process you're exec'ing using it and fetches remote environment variables, steals/mirrors incoming requests of your target (in k8s), gives you outgoing access as if your process is deployed in the cluster.

It loads into the process using DYLD_INSERT_LIBRARIES and LD_PRELOAD but it propagates its own configurations using environment variables (prefixed with MIRRORD) but also turbo strips the env fetched from the remote.

We discovered the incompatibility issue when user first used turbopack, then suggested to use turbo.json as a workaround. Then other users started using next dev --turbopack and that failed too - but we can't provide a workaround for them besides not using turbo since there's no way to let mirrord environment variables be propagated.

The issue on our side is metalbear-co/mirrord#3651

[anthonyshew]

Is this a feature request for Turbopack?

[aviramha]

Yes - I think so, I am a bit confused myself (not too knowledgable in the Turbo/Vercel ecosystem). I am talking about the part that runs when doing next dev --turbopack which I think exists in this repository even though its called Turborepo

[aviramha]

I had a chat with @timneutkens and he explained me why I'm super confused. I understand more what's going on and probably I just wasted your time - so apologies for that.