[rush] Tree of rush-managed projects that contain rush-managed projects?

[trusktr]

This is more for discussion; not a bug or feat request.

Can we have a tree of rush-managed projects?

For example, can we have a rush repo with packages in it, where each "package" may be from another repo that uses rush to manage multiple packages?

I'm just wondering if this may be doable. Because sometimes it makes sense to split a package into several closely-related packages, but these packages may be completely un-related to a rush-managed application that consumes them.

So the structure might be:

my-app
  src/ # a "package" managed by rush
  packages/ # other "packages" managed by rush
    one/
    two/
    three/ # this "package" is actually made of several sub-packages. It is placed here as a git submodule, lives outside of this repo.
      src/ # a "package" managed by rush
      packages/  # other "packages" managed by rush
        four/

In that example, three might be some package that has no idea about app, and it makes sense for three not to know anything about my-app. my-app might be made by one person, and three by another person, in separate github accounts, and the author of my-app may want to adopt the three package into the my-app project not as a dependency from NPM, but as a git submodule so that editing the source is possible.

Any experience with this sort of thing? I imagine it is perfectly doable; the parent rush project managing the commands needed to manage the rush sub-project.

[trusktr]

Turns out I discovered this isn't currently possible, because there may be issues related to https://github.com/microsoft/rushstack/issues/1702.

rush would need to traverse up to find the nearest rush.json, and from that tree-node in the tree of rush projects it could lookup sub-folder projects and know if the current working directory is one of those projects.

There may need to be a new rule or two regarding project paths. F.e.:

• sub-folder rush.json files would override parent-folder rush.json projects.
  • Given a parent-folder rush.json that has an project listed in projects, rush goes into the path for that project, then traverses up to find the nearest rush.json (which would be further down than the original rush.json if it isn't the same rush.json), and finally uses that location as the basis for operation (as if we had already been in that folder to begin with when we ran the initial command). This will work great due to how rush handles varying rush versions already (i.e. when using rush as a globally-installed package and it detects the version of rush to use in the current project).