Personally, I prefer to use scripts. This would result in commands such as yarn package instead of yarn grunt package. This can still be modified in the current PR if wanted, but I'd like to discuss it prior to changing it.

How about we add a note that you don't have to install grunt-cli globally if you prefix the grunt commands with yarn?

@Narretz Do you mean to undo the changes of this commit and only add the note ?
What's the point of using the global grunt cli by default? Using global modules for these kind of things doesn't have any benefits, does it?

My reading of this PR is that it is not using a global grunt install anymore.

Using global modules for these kind of things doesn't have any benefits, does it?

It does have the benefit that you don't have to prefix each command with yarn . That's 5 keystrokes.

Do you mean to undo the changes of this commit and only add the note?

That's right. Another problem is that this is not the only place where these instructions are. There's also https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md, https://github.com/angular/angular.js/blob/master/README.md, even on the angularjs.org repo: https://github.com/angular/angularjs.org

Personally, I prefer to use scripts. This would result in commands such as yarn package instead of yarn grunt package.

For better or worse, we are using grunt as our task runner. At this point, I don't see much benefit in implementing "aliases" for all grunt commands (and having to keep the yarn scripts up-to-date with the grunt commands in case we add/remove any).

How about we add a note that you don't have to install grunt-cli globally if you prefix the grunt commands with yarn?

I would go the other way and document that you can drop the yarn part in yarn grunt ... if you install grunt globally (but keep the uing the local version "by default").

👍 for updating all places which refer to grunt commands 😃

At this point, I don't see much benefit in implementing "aliases" for all grunt commands

Ye makes sense.

Using scripts does hide the actual implementation from the usage of the commands (whether you're using grunt, gulp, webpack, pure node, ... you can still use the same cli command).

As AngularJS is using both Grunt and Gulp (atleast, they are both installed), one could run grunt and gulp without the user/developer needs to know which one he is running by using scripts. Currently, I have no idea what Gulp is being used for (afaik I shouldn't need to know it and just rely on the scripts).

But yes, the downside is you need to maintain the scripts.

If we document yarn grunt ... as default, with the option to install grunt-cli globally, then that's fine with me

This PR must / can be updated now. There's now things to change in the DEVELOPERS.md, too.

Alright, I've moved the changes to the new files. I didn't add the message regarding global gunt yet, will do soon.

I was wondering how the following ended up in there and I wanted to check if this is really necessary ?

Note: If you're using Linux, and yarn install fails with the message 'Please try running this command again as root/Administrator.', you may need to globally install grunt and bower:

I've had this problem on my mac for a while (prior to my npm permissions where set correctly).
Imho this should not result in global installation of the npm packages, instead there could be two solutions:

• sudo the local commands (but we don't want that)
• fix permission issues.

Or am I missing something why the global installation is really required? Is it realy up to us to define how they have to fix their permission issues ? We might be good with linking to https://docs.npmjs.com/getting-started/fixing-npm-permissions, no ?

I always go to the git blame to find why something was added. Leads to result in 50% of the cases. ;)
This was originally added for npm and then simply changed to yarn. 1dedcdf#diff-acca20ff7c21d5e56c51120c19837a7fL81 I'm okay with adding a link to yarn docs for permission issues.

I've added the mentioning of installing grunt globally:

Grunt: We use Grunt as our build system. We're using it as a local dependencies but if you prefer to use the command-line tool globally, you can install it using yarn:

yarn global add grunt-cli

I'm still a bit unsure what the benefit is for adding this to the docs, as it realy is not recommended (it's even recommended to avoid it) to install it globally. If it's not recommended, why guide anyone to adding it globally ?

Because then you can grunt ... instead of yarn grunt ... At the moment, the message isn't very helpful if you don't mentiond that you can skip the yarn part in that case. And the Grunt docs still advise that you install the cli globally.
The yarn docs also say there are use cases for global adding: https://yarnpkg.com/lang/en/docs/cli/global/

Let me add that part aswell.

Because then you can grunt ... instead of yarn grunt ...

Even tho thats true, the issues global NPM modules can cause are worse.
Imagine contributing to several projects, each using a seperate, globally, grunt version ... This is pretty much something I had issues with when I tried setting up angularjs for the first time due to the global grunt, iirc I had to remove my other global installed grunt (which was my own mistake, as I should not have had grunt globally in the first place).

I do agree that if that's not the case, installing it globally results in "shorter" commands. But promoting the global installation is odd as it's realy something to be avoided at all cost.

And the Grunt docs still advise that you install the cli globally.

Sadly, alot of libraries mention it coz it's easier to explain how the CLI works without explaining how NPM/Yarn resolves dependencies (localy vs global) and how scripts work (which is out of scope of the grunt docs anyway).

The yarn docs also say there are use cases for global adding

Ofcourse there are. Every none-project dependency should be globally (yarn, yeoman, angular/cli, ...).
Every project dependency should be in the project in such a way that the project is as self-contained as possible, resulting in less hassle to setup a project.

Anyway, I've added the message 😄