A single NPM install: In one step, Rush installs all the dependencies for all your projects into a common folder. This is not just a “package.json” file at the root of your repo (which might set you up to accidentally
require()a sibling’s dependencies). Instead, Rush uses symlinks to reconstruct an accurate “node_modules” folder for each project, without any of the limitations or glitches that seem to plague other approaches.
⏵ This algorithm supports the PNPM, NPM, and Yarn package managers.
Automatic local linking: Inside a Rush repo, all your projects are automatically symlinked to each other. When you make a change, you can see the downstream effects without publishing anything, and without any
npm linkheadaches. If you don’t want certain projects to get linked, that’s supported, too.
Fast builds: Rush detects your dependency graph and builds your projects in the right order. If two packages don’t directly depend on each other, Rush parallelizes their build as separate NodeJS processes (and shows live console output in a readable order). In practice this multi-process approach can yield more significant speedups than all those async functions in your single-threaded Gulpfile.
Subset and incremental builds: If you only plan to work with a few projects from your repo,
rush rebuild --to <project>does a clean build of just your upstream dependencies. After you make changes,
rush rebuild --from <project>does a clean build of only the affected downstream projects. And if your toolchain is package-deps-hash enabled,
rush builddelivers a powerful cross-project incremental build (that also supports subset builds).
Cyclic dependencies: If you have hammers that build hammer-factory-factories, Rush has you covered! When a package indirectly depends on an older version of itself, projects in the cycle use the last published version, whereas other projects still get the latest bits.
Bulk publishing: When it’s time to do a release, Rush can detect which packages have changes, automatically bump all the appropriate version numbers, and run
npm publishin each folder. If you like, configure your server to automatically run
rush publishevery hour.
Changelog tracking: Whenever a PR is created, you can require developers to provide a major/minor/patch log entry for the affected projects. During publishing, these changes will be automatically aggregated into a nicely formatted CHANGELOG.md file.
Enterprise policies: Want to review new libraries before developers add them to package.json, but avoid hassling people about already approved cases? Want to enforce that all your projects depend on the same library version numbers? Are unprofessional personal e-mail addresses accidentally showing up in your company’s Git history? Rush can help maintain a consistent ecosystem when you’ve got many developers and many projects in the mix.
Lots more! Rush was created by the platform team for Microsoft SharePoint. We build hundreds of production NPM packages every day, from internal and public Git repositories, for third party SDKs and live services with millions of users. If there’s an important package management problem that needs solvin’, it’s likely to end up as a feature for Rush.