Nathan Hammond

In this scenario you have a `pnpm-lock.yaml` and a `package-lock.json` in the root. No matter what we attempt to detect it will make _somebody_ unhappy. There is no reasonable way...

I have no reason to believe that this won't work, you can see two test runs: - [Stops just before publishing.](https://github.com/nathanhammond/turborepo/runs/7992866262?check_suite_focus=true) - [Skips publishing, but commits the changes.](https://github.com/nathanhammond/turborepo/runs/7993356354?check_suite_focus=true) The actual...

Thanks for your comments, I've gone back and added commentary into the files to make sure that the information is not lost.

@theJoeBiz we suspect that this has been superseded by https://github.com/vercel/turborepo/pull/2019, with support released in 1.5. Thank you for the early pass which helped us understand the shape of the problem!

Cross-linking a post on the PR: https://github.com/vercel/turborepo/pull/1361#issuecomment-1153545093 As a quick ergonomics fix: `pnpm -- turbo run build --filter=docs` is what you're looking for.

Hey @faustbrian! Thanks for the report! Even though it doesn't stop at the same package every time, does `turbo` *stop* every time? Can you also share your `pnpm-workspace.yaml` to help...

Last question: is it possibly timing out after spending a certain amount of time running the process? Or is the duration of the execution before stopping also inconsistent? (Just trying...

I suspect what is happening here is the following: 1. During post-install, `turbo` replaces the binary at `bin/turbo` with the native binary. 2. The restored version from the cache has...

This may have actually been fixed as a side effect of a cache behavior update that appears in 1.6. I haven't tested that hypothesis, but I suspect we now do...

So, a couple of things: 1. We have made some modifications to our default hashing pattern to include the `package.json` of each package into the task hash in a way...