Clone this wiki locally
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.
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
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 dorky personal e-mail addresses 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.
3 Minute Demo
See Rush in action! From your shell, install the tool like this:
$ npm install -g @microsoft/rush
For command-line help, do this:
$ rush -h
To see Rush build some real projects, try running these commands: :-)
$ git clone https://github.com/Microsoft/web-build-tools $ cd web-build-tools $ rush install $ rush install # <-- instantaneous! $ rush rebuild $ rush build # <-- instantaneous!
(If you don't have a GitHub account set up, you can use
rush install --bypass-policy.)
If someone already set up Rush for your repo, and you just need some instructions...
- Everyday commands - learn how to install packages, build your projects, and more.
- NEWS - See what's happening with Rush and other web-build-tools projects
- Rush FAQ - Frequently Asked Questions
If you're a repo maintainer who wants to adopt Rush...