RFC: New Task Filtering Syntax #105
Replies: 6 comments 3 replies
-
|
I've also noticed that the current --scope option behaves a little weird. I have a few applications and one app depends on another (AppA depends on AppB) and if I run |
Beta Was this translation helpful? Give feedback.
-
|
As one of the original requestors let me try and argue why the pnpm If I write `pnpm run lint --filter="...C". I know it's going to run "A, B, C" because I look to the left of "C" in the dependency chain. Same for "C..." I just look to the right. The dots match up with the left and right of the chain. |
Beta Was this translation helpful? Give feedback.
-
|
Would this solve? #417 |
Beta Was this translation helpful? Give feedback.
-
|
Unfortunately, not yet. There is one further feature required, which is splitting entrypoint selection (your app) from the resolution of pipeline dependencies (build all of its dependencies). Currently, unless your app's dependencies are also selected by the combination of |
Beta Was this translation helpful? Give feedback.
-
|
I filed #912 to track the issue |
Beta Was this translation helpful? Give feedback.
-
|
actually working pretty great in canary.4, thanks @gsoltis . added to my package.json |
Beta Was this translation helpful? Give feedback.
-
|
How about tagging system in the https://youtu.be/LUSPTD0Ithc?t=1085 |
Beta Was this translation helpful? Give feedback.
-
|
huge +1 for a more flexible tagging setup. In my case I'd end up marking various packages with parts of the stack (ex: This coupled with using filters in pipeline/dependencies would be huge. cc @jaredpalmer |
Beta Was this translation helpful? Give feedback.
-
|
The new See the documentation here: https://turborepo.org/docs/features/filtering |
Beta Was this translation helpful? Give feedback.
-
Problem
The current filtering options in the CLI aren't very expressive. They are modeled after Lerna's
--scopeflag. There are certain useful situations which are not really possible at the moment. One of them being executing things up to but not including a certain package task.Impact / Context
This issue was raised by Lattice.com and Makeswift.com who both wanted more control over task filtering.
Solution
Adopt PNPM's filtering syntax for
turbo runand maketurbo runa pass through/default likeyarn <cmd>. Selectors may be specified via the--filterflag:–filter <package_name>
To select an exact package, just specify its name (
@scope/pkg) or use a pattern to select a set of packages (@scope/*).Examples:
–filter <package_name>…
To select a package and its dependencies (direct and non-direct), suffix the package name with an ellipsis:
<package_name>.... For instance, the next command will run tests offooand all of its dependencies:turbo test --filter foo...You may use a pattern to select a set of root packages:
–filter <package_name>^…
To ONLY select the dependencies of a package (both direct and non-direct), suffix the name with the aforementioned ellipsis preceded by a chevron. For instance, the next command will run tests for all of
foo’s dependencies:–filter …<package_name>
To select a package and its dependent packages (direct and non-direct), prefix the package name with an ellipsis:
...<package_name>. For instance, this will run the tests offooand all packages dependent on it:turbo test --filter ...foo–filter “…^<package_name>”
To ONLY select a package’s dependents (both direct and non-direct), prefix the package name with an ellipsis followed by a chevron. For instance, this will run tests for all packages dependent on
foo:–filter ./
To only select packages under the specified directory, you may specify any relative path, typically in POSIX format.
–filter {}
Includes all projects that are under the specified directory.
It may be used with the ellipsis and chevron operators to select dependents/dependencies as well:
It may also be combined with
[<since>]. For instance, to select all changed projects inside a directory:Or you may select all packages from a directory with names matching the given pattern:
–filter “[]”
Selects all the packages changed since the specified commit/branch. May be suffixed or prefixed with
...to include dependencies/dependents.For example, the next command will run tests in all changed packages since
masterand on any dependent packages:Multiplicity
When packages are filtered, every package is taken that matches at least one of the selectors. You can use as many filters as you want:
turbo test --filter ...foo --filter bar --filter baz...Excluding
Any of the filter selectors may work as exclusion operators when they have a leading “!”. In zsh (and possibly other shells), “!” should be escaped:
\!.For instance, this will run a command in all projects except for
foo:And this will run a command in all projects that are not under the
libdirectory:–filter-prod <filtering_pattern>
Acts the same a
--filterbut omitsdevDependencieswhen selecting dependency projects from the workspace.–test-pattern
test-patternallows detecting whether the modified files are related to tests. If they are, the dependent packages of such modified packages are not included.This option is useful with the “changed since” filter. For instance, the next command will run tests in all changed packages, and if the changes are in the source code of the package, tests will run in the dependent packages as well:
–changed-files-ignore-pattern
Allows to ignore changed files by glob patterns when filtering for changed projects since the specified commit/branch.
Usage example:
Discussion
One thing I (@jared) don’t care for in the above is the meaning of the
.... I actually think PNPM (which the above knocks off) has it exactly backwards. For example, tobuildin a package and its own dependencies (that is the things listed it its ownpackage.json, you run this in pnpm:pnpm build --filter=front.... II find this pretty awkward and hard to remember. I think preceding
...should be dependencies and...after should be dependents. To me this would make it closer to the English usage of ellipses:Unfortunately, this is exactly backwards in PNPM.
Turbo can run multiple commands at the same time. I wonder if we tweaked the syntax to combine the build target and the filter into one single block:
turbo ...{./packages/*}::build[origin/master] ...^::thing#testWe would need to alter the DSL to remove ambiguity.
::would delimit an npmpackage.jsonscript. However, it should required for disambiguation so thatturbo buildandturbo testetc. are the same asturbo ::buildandturbo ::testturbo currently uses
^in the pipeline definition to express a topological task relationship. We should switch this to...in order to make the filtering syntax and pipeline congruent.{ "turbo": { "pipeline": { "build": { "dependsOn": ["^build"] // this should be ... }, } } }turbo currently uses
#as a delimiter (e.g.<package>#<npm-pkgjson-script>) in pipeline definition for package task-specific overrides. We should switch to::for congruency with filtering.{ "turbo": { "pipeline": { "build": { "dependsOn": ["^build"], "outputs": ["dist/**"] }, "front#build": { // this should become :: to match CLI filter "dependsOn": ["^build"], "outputs": ["dist/**"] }, } } }Note: the reason we can’t use
.as the delimiter is because a.is allowed in NPM package names (e.g.lodash.mapkeysis a valid package).Beta Was this translation helpful? Give feedback.
All reactions