search

Azure / azure-sdk-for-js

This repository is for active development of the Azure SDK for JavaScript (NodeJS & Browser). For consumers of the SDK we recommend visiting our public developer docs at https://docs.microsoft.com/javascript/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-js.
MIT License
2.09k stars 1.2k forks source link

Don't recommend global install of rush #5105

Closed christopheranderson closed 5 years ago

christopheranderson commented 5 years ago

Problem

Global installation of project specific tools like rush is (imo) an anti-pattern. Just as you would not install typescript globally anymore, same would apply for rush. It makes it so different projects using different versions of a dependency have to clean up their global installs to fix it. There is additional friction, as well, when switching between Node versions as most folks have their global modules follow their Node version. Additionally, if rush makes a breaking change and the project isn't updated (or you're working on a older maintenance branch which wasn't updated), then you have to update all the docs on which version of rush to install. Ditto for picking up hotfixes/new features/etc. even without a breaking change.

Personally, I global install this and then delete it each time right now because I hate leaving my globals polluted because it is a huge pain to debug dependency resolution issues with global packages.

Proposed solutions

  1. Make @microsoft/rush a dev dependency. People can then use npx rush ... for their rush commands. (yes you can do this without the dev dependency, but then you don't solve the breaking change issue without telling folks to specify a version everytime. blech.)
  2. Make @microsoft/rush a dev dependency. Add npm scripts for all the rush commands so we don't leak the dependency on rush. This allows the repo ES to be more flexible without breaking people's workflows.
kurtzeborn commented 5 years ago

@christopheranderson The decision to use rush to manage our dependencies and JS builds was not taken lightly. Having a predictable build was the main thrust here. What's stopping you from installing it locally in a folder and adding it to your path when needed rather than globally installing it?

CC: @mikeharder, @bterlson

mikeharder commented 5 years ago

CC: @bsiegel

bsiegel commented 5 years ago

One additional wrinkle is that Rush uses pnpm as the package manager under the hood. Using both npm (to install rush) and pnpm in the same repo is definitely going to cause problems.

@christopheranderson The solution here is the same as we use in CI - for simplicity we recommend that devs who are working in the repo install Rush globally, however the repo does contain scripts that will automatically acquire and run the correct Rush version. Anywhere that the docs tell you to run rush you can instead run node common/scripts/install-run-rush.js (and likewise for rushx). The script downloads and caches the tool to a temporary directory per Node version, so the experience should pretty much mirror using Rush as a global tool. The downside is that you will have to provide the relative or full path to the script every time, whereas with a global install the rush and rushx binaries are automatically available on your $PATH.

I can definitely add this to the docs, I'm sure you're not the only one who's irked by global tool installs.

bsiegel commented 5 years ago

You could probably add some aliases to make this easier to manage, let me know if this is helpful:


alias rush='node $(git rev-parse --show-toplevel)/common/scripts/install-run-rush.js'
alias rushx='node $(git rev-parse --show-toplevel)/common/scripts/install-run-rushx.js'