This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/vercel/turbo-site/5fPGSA6xr7TDBitcDaDKcxKZoCfo
✅ Preview: https://turbo-site-git-gsoltis-plancmd.vercel.sh

@weyert serialized graph is a different matter which we are going to support. The goal here is to increase observability and unblock folks using Ignore Command on Vercel/Netlify and also ppl using dynamic pipelines in CircleCI and GitLab CI.

@jaredpalmer re: cleaning up e2e tests, I think we need to be able to check "packages in scope", "tasks to be run", and "what was run from cache".

As currently implemented, plan gives us "packages in scope". Maybe plan is not the best term for that functionality, since it suggests "things that will be run", which is more like "tasks to be run". Perhaps the command here is better described as affected? It answers the question of "given these flags (--since, --scope, etc.), what packages are in scope?". Then a true plan would be "tasks to be run", a superset of "packages in scope". We don't technically need both, could even have a --packages-only flag to the "tasks to be run" command. What do you think, should we implement that instead?

I'm not sure I have a strong opinion on a separate command vs flag to run. Internally we can make the code sharing work out either way. My inclination is towards separate command because not all of the flags for run apply and that could lead to some documentation or parsing awkwardness, but that's not necessarily a strong argument. If there's a better DX reason either way, that should probably take precedence.

As a user I think I'd prefer turbo run --dry or an variation of that. --dry/--dry-run is quite common in other tools so might be easier to understand compared to --plan

Agree with @alexandernanberg —dry makes sense. Obvs let’s keep the abstraction needed to get the graph and scope outside of run command. These will be useful for the query commands we chatted about in our sync yesterday.

I think --dry-run would be fine for showing the tasks that would be run. That will require extricating the task graph a bit, but that's work we need to do anyways. I'll get that going in a separate PR and then we can layer on top of that.

Closing in favor of #862