Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 90292b3452
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
branchseer
changed the title
branchseer
changed the title
--concurrency-limit and --parallel
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d9480733bb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Add `--concurrency` to limit the number of concurrent tasks per execution graph level (supports numbers and percentages like `50%`), and `--parallel` to discard dependency edges and run tasks independently. Both flags are per-level: nested `vp run` inherits the parent's concurrency unless it specifies its own `--concurrency`. When `--parallel` is used without `--concurrency`, concurrency is unlimited. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Rename flag from --concurrency to --concurrency-limit - Reduce default concurrency from 10 to 4 - Remove percentage format support (e.g. 50%) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Flags must appear before the task name. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…IT env var Remove the implicit context-based concurrency inheritance. Instead, use the VP_RUN_CONCURRENCY_LIMIT environment variable (which naturally passes through to child processes since VP_* is already untracked). Priority order: --concurrency-limit flag > VP_RUN_CONCURRENCY_LIMIT env > --parallel (unlimited) > default (4). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Only show the interactive task selector when no execution flags (--concurrency-limit, --parallel) are present - Cap semaphore permits to Semaphore::MAX_PERMITS to avoid panic when concurrency_limit is usize::MAX (from --parallel) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
--parallel takes priority over VP_RUN_CONCURRENCY_LIMIT, not the other way around. The code was correct; the docs and comments were not. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Package b depends on a, so without --parallel they run sequentially. Both use a barrier requiring 2 participants — completing without timeout proves --parallel discards edges and runs them concurrently. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
branchseer
force-pushed
the
feat/concurrency-parallel
branch
from
cc179dc to
7735322
Compare
|
|
||
| Useful for starting dev servers that all need to run at the same time. Same behavior as `--parallel` in pnpm. | ||
|
|
||
| To ignore dependency order but still cap concurrency, combine both flags: |
There was a problem hiding this comment.
Not sure if this is a good pattern to introduce. IMO it should all be driven by the task graph as that should be treated as a source of truth in a monorepo (my personal opinion). ignoring dependency order should therefore not be necessary, especially because if the dependency order is messed up, caching is not reliable anymore which could lead to issues if this flag is misused.
What do you think about not adding a --parallel flag, but instead achieving the "infinite" upper bound with with --concurrency-limit=none?
There was a problem hiding this comment.
Some tasks can be executed in any order, regardless of package dependencies, such as linting and dev servers.
This should ideally be configured per-task. However, we should also allow users to use Vite Task as a lightweight script runner (replacement for npm run), which requires no additional configuration beyond package scripts.
3 participants
Summary
--concurrency-limitflag to control the number of tasks running at the same time.--parallelflag to ignore task dependencies and run all tasks at once with unlimited concurrency (unless--concurrency-limitis also specified)🤖 Generated with Claude Code