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

.direnv causes issues with bun + solidstart #547

Open
HPsaucii opened this issue Feb 3, 2025 · 1 comment
Open

.direnv causes issues with bun + solidstart #547

HPsaucii opened this issue Feb 3, 2025 · 1 comment

Comments

@HPsaucii
Copy link

HPsaucii commented Feb 3, 2025

I'm using essentially vanilla bun + solidstart, and for whatever reason, whenever the .direnv directory is present, it causes bun run vinxi dev (aliased to bun dev) to infinitely use ram and CPU without launching the webserver.
Works with direnv on it's own
Works with direnv+nix-direnv, aslong as .direnv is moved to somewhere outside the project
breaks with direnv+nix-direnv, with .direnv in the default location (project root)

@bbenne10
Copy link
Contributor

bbenne10 commented Feb 3, 2025

This sounds like a problem with direnv, bun or solidstart, not with nix-direnv. Nix-direnv doesn't particularly care where your direnv cache is - we just write and read it. I want to say it is likely a problem of creating new shells infinitely and getting caught in the resultant recursive invocation of direnv, but that doesn't explain why direnv itself works with the default cache location. Is there something in this set up that finds scripts and execs them without knowing where they came from?

While I don't think this is a nix-direnv problem, maybe a small reproduction repository will help you isolate the badly behaving software or give us a way we can look over it to help you out?

EDIT: New question: Does this reproduce with node instead of bun?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants