yerna icon indicating copy to clipboard operation
yerna copied to clipboard

Make tree-traversal flags composable

Open nomcopter opened this issue 7 years ago • 3 comments

Grouping would make tree-traversal commands much more powerful.

Example API

With dependencies as follows:

A -> B
A -> C
B -> D
Z -> Y
Z -> B
  • yerna list (--include A --dependencies) --exclude A to output: B, C, D
    • Useful for building the dependencies of a package (after pulling for instance)
  • yerna list (--include A --dependencies) (--exclude Z --dependencies) to output: A, C
    • This is useful for running test suites without duplication

Although I doubt parentheses are the right option here.

nomcopter avatar Mar 23 '18 01:03 nomcopter

There's already the --dependencies flag for the first case, though it'll also build A too. I think things will get messy if you try to differentiate between packages included directly and packages included transitively, especially when you're using multiple include/exclude rules. Plus, there's a nice consistency to all packages being treated the same, rather than specializing on direct includes. Is it that bad for you to build A in this case?

I'm not sure I understand the use case or precise semantics of the second feature. yerna already only runs tasks once for each package no matter how many times they appear in the dependency DAG of your selected packages, so I'm not sure what duplication you mean.

Anyway, all that said, I think between this and #28 there are some good possibilities for a well-thought-out set of flags for precisely choosing and pruning which parts of your dependency graph you want. This is probably something that Lerna could benefit from too.

seansfkelley avatar Mar 23 '18 16:03 seansfkelley

In my example above, A and Z are "leaf" packages - they are the actual useful bundled pieces produced by my monorepo.

  1. yerna list --include-dependencies A is useful after pulling changes from the repo because I want to build all of its dependencies but I want to run the development mode for A (its production build takes forever).

  2. I have two separate CI builds for A and Z as they produce two different resulting artifacts (docker containers). Separating these builds is useful for parallelization and to reduce the asset size in the bundled result. However, if I yerna run test for both A and Z, I end up running the tests for many packages twice.

nomcopter avatar Mar 23 '18 18:03 nomcopter

Updated title and top level comment.

nomcopter avatar Apr 16 '18 20:04 nomcopter