Fluentui: Question: Are you moving away from Rush? If so, why?

[Thisen]

I know you suggest putting questions on Stack Overflow, but this is more a question to your build tooling.

As the title says:

Are you moving away from Rush?
If so, why?

The context of this question is that I've recently introduced Rush to my company and we're started using it. I've used this repository as a reference of how Rush scales and works in a monorepo. It concerns me that it looks like you're moving to a Lerna-based monorepo.

[kenotron]

@dzearing has a much better answer than I right inside the PR:

I think there is pretty big benefit in having consistency with the OSS community, and in particular the React and React-Native communities where lerna and yarn are used pretty universally. Many of our component library partners (Teams with Stardust, FastDNA) all use lerna already. As does midgard repo, as do other OSS ux libraries such as material-ui and so making this step brings us closer to a more common OSS stack. Lerna has a larger community, stackoverflow help, etc.

Maybe the most interesting bit is the Dependabot support here: https://dependabot.com/blog/lerna-support/

[apostolisms]

It is healthy for teams to experiment with different tools and compare pros and cons. Rush is used by a variety of teams within Microsoft and is actively supported. We don’t dictate how teams do their work or what tools to use, there is a lot of autonomy to experiment with different approaches and we all benefit from that.

[octogonz]

People tend to think of tool chains as relatively simple little bricks that you throw together so you can get your "real" project built and released. This is really not the case, especially in the NodeJS world, especially when you're shipping serious products. We've found that tool chains are complex software spaces all to themselves.

There's a real value in having different options that cater to different audiences. As a comparison, the React/Angular/Ember/Vue/etc discussion isn't about which one will "win". It's about what features are users demanding today. And which option is the best fit for your team. Having different projects coming at a problem from different perspectives is healthy. It benefits everyone. For example when React came along with Virtual DOM, Ember answered with Glimmer, and then you got Incremental DOM and other takes on it. In some technical sense these options are redundant, but each one brought something unique and valuable to our industry. And the project owners were encouraged -- not discouraged -- to see some competition.

It's notable that Fabric's switch to Lerna simultaneously involved changing the package manager, and also creating beachball, and also implementing new features for just-task . This really demonstrates that while Rush and Lerna have some overlap, they aren't simple bricks that can be swapped out. The tradeoffs are complicated!

The audiences are somewhat different, too. I can talk about that because I personally worked on Rush since its beginning (which is just as old as Lerna). We took a somewhat corporate approach to it, putting a lot of effort into design discussions, code reviews, tests, validation, documentation, compatibility, support, etc. The software itself has this mindset, too, with safeguards, schemas, review policies, publishing workflows, etc. We care a lot about nuances like phantom dependencies, that are mainly the concern of a repo that has a lot of teams and projects in the mix. Recently we've been working hard to make it appeal to the general community, but it nonetheless reflects a lot about its origin.

Lerna is more organic and lightweight, and arguably more flexible, especially if you're just getting started. Clearly a lot more GitHub projects have jumped on that bandwagon. I'm content to see Rush's community growing, though. And to see Microsoft allocating more full-time people to work on it. I'm super excited about all the features that are coming next.

But I don't hope for _everyone_ to use Rush. Broadening the scope that wide would likely compromise its strengths. Each team should consider their own needs, and pick the best option for the job. Although Fabric claims to be simply following the herd, they're clearly tackling new problems and writing lots of toolchain code, which is cool and interesting to watch. Maybe we'll learn something from it!

[dzearing]

Well said @octogonz. Rush is a great tool. I also worked on it, and it is still being improved as we have many teams using it. The work with lerna and yarn here is an experiment. If there are better or worse things about it, we can learn from that. Our goal is to constantly improve, try things, and make sure the stack keeps devs productive. If it doesn’t meet our needs or creates too much friction, we can revert. We can also see what makes sense to improve with rush or in lerna. Lots of opportunities.