octogonz
commented
5 years ago This is an important feature that we've been wanting to build for a long time.
You already can simulate it to some extent today. Suppose we have:
repo-a/rush.json
"projects": [
{
"packageName": "lib1",
"projectFolder": "libraries/lib1"
},
{
"packageName": "lib2",
"projectFolder": "libraries/lib2"
}
]repo-b/rush.json
"projects": [
{
"packageName": "lib3",
"projectFolder": "libraries/lib3"
},
{
"packageName": "my-app",
"projectFolder": "applications/my-app"
}
]And then suppose you created this folder:
bridge/rush.json
"projects": [
{
"packageName": "lib1",
"projectFolder": "../repo-a/libraries/lib1"
},
{
"packageName": "lib2",
"projectFolder": "../repo-a/libraries/lib2"
},
{
"packageName": "lib3",
"projectFolder": "../repo-b/libraries/lib3"
},
{
"packageName": "my-app",
"projectFolder": "../repo-b/applications/my-app"
}
]When you run rush update in this folder, it should install the union of the dependencies from both repos in a new bridge/common/temp and then link everything together as expected. On a whiteboard, it's essentially a correct solution. But with one caveat: The two repos need to have consistent versions. (If you're familiar with the Evergreen and XStitch internal tools that coordinate dependency upgrades across repos: In order for a rush bridge repo to build, the Evergreen/XStitch branch cannot be in a broken state. Otherwise when you try to use rush bridge to test a fix, instead you'll find yourself involved in work that is equivalent to an Evergreen/XStitch fixup effort.)
So the theory is simple and straightforward. In practice, there are a bunch of loose ends that need to be tied up however (which is why I've tagged this issue as "needs design"):
- We need to reconcile the common-versions.json files from the two repos
- We need to handle inconsistent command-line.json file from the two repos
- We need to ignore policy warnings such as browser-approved-packages.json in this state
- If the repos use PNPM, the pnpmfile.js settings would need to get integrated somehow
- Can the shrinkwrap files be integrated? Or does
rush bridgealways need to do the equivalent ofrush update --full(and whatever work is associated with that) - If I only updated one or two projects, do I need to cross-link the entire repo? Or would it be useful to bridge only the packages that were affected by my change? (This seems like a good idea, but it can be tricky in practice due to the sometimes complex relationships between dependencies.)
Of course we don't need to sort out all these issues on day one. If someone could throw together a quick prototype of a rush bridge command, we can mark it as "EXPERIMENTAL" and iterate on it. For simple use cases, it may already be better than the manual copying/symlinking workarounds that people use today.
ThomasMichon
calebmshafer
sammarks
As discussed on an internal wbt thread, I'd like to propose a
rush bridge. The purpose would be to connect two or more Rush repos together so that:To use this tool, the user would create another
rush.jsonfile that points to several Rush repositories. This tool would then handle installing and symlinking dependencies and building as if all the known packages were in one Rush repo.Some context: My team works primarily in one Rush repository, but we have dependencies on packages from other Rush repositories and are furthermore consumed by a different downstream repository. Right now, there isn't a great way to test how changes in one package affect downstream consumers. Our current options are:
npm and pnpm, on the other hand, have support for local filesystem dependencies in standalone repos.
This would greatly help to improve our development, testing, and automation work.