Comments (8)
Ah, I see. Yes, that'd certainly be interesting but not sure if we would roadmap it as it stands. This has been the first ask for this that I've heard!
from turborepo.
Hey, thanks for the issue!
In the interest of being somewhat judicious about what we add to that list, I'd like to learn if this is a highly common use case in NixOS. I'm looking at their environment variables list and don't see the variable you're referring to. Is this something every NixOS user needs?
from turborepo.
Thanks for the quick reply!
If I'm honest, I'm not too sure about the specifics. I only discovered this environment variable after hours of debugging why my $PATH
was wrong inside child shells.
I imagine it's not listed there because it's an implementation detail—it's not something you're supposed to set yourself, rather it's set for you. I believe the issue only occurs when a tool like Turborepo prevents this environment variable from being passed down to a child shell.
cc my co-worker @samhh who may know better
from turborepo.
It comes from nix-darwin, not NixOS proper. This is the most relevant reference in the repo: https://github.com/LnL7/nix-darwin/blob/fabc653517106127e2ed435fb52e7e8854354428/modules/environment/default.nix#L195
I'd guess a significant minority of macOS Nix users use nix-darwin, and all of these will require this fix for subshells under Turbo.
from turborepo.
That being the case, I'd recommend adding that variable to your repo's passthroughs. Alternatively, you could use Loose Mode for that invocation if you're still having trouble.
Our (admittedly non-scientific) criteria for adding to the default passthroughs is to capture the most vastly common, baseline cases for the most frequently used tools, so this case doesn't sound like it fits. In my thinking, the NIX_*
namespace would be something we'd add but not __NIX_*
.
Does that make sense? Hoping I explained that well enough and it tracks with the way NixOS works from what I'm gathering from your info here.
from turborepo.
That's fair. We're successfully using a global passthrough now absent an upstream solution. Maybe you could reconsider in the future if lots of other users hit the same issue, or if it never reaches critical mass at least it's documented here now.
My only qualm is that this feels similar to the anti-pattern of placing per-user configuration in per-repo VCS ignore files, but it'd be non-trivial to solve; I don't think Turbo has a global per-user config yet?
from turborepo.
Going to close here given the above commentary.
@samhh, I'm interested, though. What do you mean by "global per-user config"?
from turborepo.
What do you mean by "global per-user config"?
Something like ~/.config/turbo/config.json
. Global passthroughs there would be analogous to global VCS ignores in ~/.config/git/ignore
.
from turborepo.
Related Issues (20)
- StyledComponents config should allow empty topLevelImportPaths & meaninglessFileNames array HOT 2
- svg with fragment not support HOT 4
- Development not running in interactive mode HOT 2
- Keypress interaction with `vite` doesn't work ("o"+Enter doesn't open web) HOT 2
- Support pnpm.ignoreOptionalDependencies when pruning lockfile
- turbo 2.0.10 prints turbo version to stderr breaking CI pipeline HOT 4
- create-turbo not working HOT 2
- Docs: Registering Root Tasks - Incorrect/Unclear example
- Misleading example in multi-language support docs
- Yarn 4: Respect `enableTransparentWorkspaces: false` when resolving workspace dependencies HOT 1
- Turbo `v2.0.10-canary.1` and newer - port forwarding stopped working (`v2.0.10-canary.0` and older is fine) HOT 1
- Docs: Add any recommendations on how to manage cache using Just-In-Time packages. HOT 1
- Issue while reading "/home/user/repo/.npmrc". Failed to replace env in config: ${NODE_AUTH_TOKEN} HOT 1
- [Linux] `turbo watch *` very often results in `discovery failed: bad grpc code`/`channel closed` error messages HOT 1
- Docs: Docs is down, just returns a 404 HOT 1
- npx create-turbo@latest - strange error starting from scratch HOT 1
- Turbo crashes HOT 7
- × invalid turbo json Error: × No "extends" key found if `./` is specified in the pnpm-workspace packages HOT 1
- breaking change from tui-term used in turborepo-vt100 breaks the building procedure when turborepo-lib used as a git dependency HOT 1
- Turborepo does not seem to make hot reload much faster HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from turborepo.