-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
feat: --only now applies to package dependencies #8163
feat: --only now applies to package dependencies #8163
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
8 Ignored Deployments
|
🟢 Turbopack Benchmark CI successful 🟢Thanks |
🟢 CI successful 🟢Thanks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not blocking, but it would be nice to have a prysk test for top level flags and their happy path behaviors.
.collect(), | ||
) | ||
} else { | ||
None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this none? shouldn't it be all?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
never mind, I saw the rest of the code and saw how allowed_tasks is used. the name of the method just threw me off
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
### Description Change `--only` so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does. Previously `--only` would still follow package dependencies resulting additional tasks getting run that weren't expected. e.g. for task definition `"test": {"dependsOn": ["build", "^test"]}` and package `a` depending on `b`, then `turbo test --filter=a --only` would result in both `a#test` and `b#test` being run. With this PR now only `a#test` will be run. I changed the `--only` logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by `--filter` and the tasks specified in the run args. This should make `--only` a far more sensible flag. ### Testing Instructions Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g. `"dependsOn": ["a#test"]`
Description
Change
--only
so it behaves in a more sensible way. It still shouldn't be widely used, but now it at least does what it says it does.Previously
--only
would still follow package dependencies resulting additional tasks getting run that weren't expected.e.g. for task definition
"test": {"dependsOn": ["build", "^test"]}
and packagea
depending onb
, thenturbo test --filter=a --only
would result in botha#test
andb#test
being run. With this PR now onlya#test
will be run.I changed the
--only
logic so now it will limit tasks in the graph to exactly those that are in the product of the packages implied by--filter
and the tasks specified in the run args. This should make--only
a far more sensible flag.Testing Instructions
Added unit tests for testing the trimming of package dependencies and task id style dependencies e.g.
"dependsOn": ["a#test"]