vercel / turborepo

Build system optimized for JavaScript and TypeScript, written in Rust
https://turbo.build/repo/docs
MIT License
26.18k stars 1.81k forks source link

Permissions issues running nextjs --experimental-https and turborepo dev #8332

Closed iamnafets closed 4 months ago

iamnafets commented 4 months ago

Verify canary release

Link to code that reproduces this issue

https://github.com/iamnafets/experimental-https-repo

What package manager are you using / does the bug impact?

Yarn v2/v3/v4 (node_modules linker only)

What operating system are you using?

Mac

Which canary version will you have in your reproduction?

turbo@npm:2.0.1

Describe the Bug

When running --experimental-https, I get a different set of errors in turbo dev vs when just running.

Without turbo:

➜  web git:(main) ✗ yarn dev
 ⚠ Self-signed certificates are currently an experimental feature, use at your own risk.
   Attempting to generate self signed certificate. This may prompt for your password
   CA Root certificate created in /Users/iamnafets/Library/Application Support/mkcert
   Certificates created in /Users/iamnafets/Dev/my-turborepo/apps/web/certificates
   Adding certificates to .gitignore
   ▲ Next.js 14.1.1
   - Local:        https://localhost:3000

 ✓ Ready in 1210ms

With turbo:

image

(Not being able to copy/paste is kind of annoying)

Expected Behavior

Expect the task to work identically inside turbo and outside.

To Reproduce

Checkout the repro repository, run yarn install, yarn dev.

Additional context

I'm thinking this has to do with the strict behavior. Unclear.

iamnafets commented 4 months ago

I can't find a reference to how to enable "loose mode" in the documentation.

NicholasLYang commented 4 months ago

Hi @iamnafets, you can enable loose mode by passing --env-mode loose in your turbo command

iamnafets commented 4 months ago

Yeah that works thanks! Is there any way to bisect the necessary env variables?

iamnafets commented 4 months ago

Nevermind, was able to do this with env -i and running the command. Turns out I need $HOME. For completeness, the fix for this issue is to add HOME to the env of the dev command.