Reword warning about npm to remove incorrect implications

[forivall]

The warning about npm is overwhelmingly FUDdy and implies that yarn has better security than npm in their typical usage by mentioning the lack of cryptographic package signing in npm, which is also absent in yarn. also, newer versions of npm are deterministic in their installation (npm 5), and so I added a description of how installation via the OS-specific method solves that problem.

also, just in terms of phrasing, stating the conclusion first and then describing the reasons frames the statement that there's a reason why we're doing this, rather than giving a bunch of statements, and then providing the conclusion, which leaves the reader to unnecessarily construct additional conclusions relating to npm's dependability.

[Daniel15]

by mentioning the lack of cryptographic package signing in npm, which is also absent in yarn

This paragraph is talking about installation of yarn itself. It's correct - Yarn is GPG signed (for the tarball, Debian and RPM packages) and Authenticode signed (for the Windows installer). npm doesn't support any of these. The fact that Yarn just checks SHA like npm does is not relevant in this section, as you never install Yarn via Yarn.

newer versions of npm are deterministic in their installation (npm 5)

npm 5 is not out of beta yet, so the current text is still accurate until a stable release of npm 5 is out. Additionally, I think we'd need to add an npm lockfile to ensure dependencies are installed deterministically, so this is still an issue. So far I haven't seen any confirmation that installing global packages via npm 5 is deterministic or that it uses the lockfile.

Have you confirmed that adding an npm lockfile results in dependencies for global packages being installed deterministically when using npm 5?

[forivall]

Nevertheless, by not scoping the original assertion about to only installation of yarn causes unnecessary FUD, and leaving the reader to assume that yarn must haves solved this problem.

I haven't confirmed the deterministic nature of npm, but in my experience, for fresh installs, I haven't seen nondeterministic installs since the npm3 flattening change. I'll confirm that later.

Installation of npm with npm is deterministic because they use bundledDependencies. I'm curious why the same hasn't been considered for yarn, at least for the version pushed to npm.

[jamiebuilds]

The paragraph appears to be correct as is, closing

[forivall]

@thejameskyle no, the statement about npm being non-deterministic is incorrect. It provides deterministic installs if an npm-shrinkwrap.json is present. Even better, if the bundledDependencies array is populated, then all of the files are included when the package is packaged.

[Daniel15]

Before merging a PR like this one, we'd need to: 1. Update Yarn to use npm shrinkwrap (for example, autogen it based on the Yarn lockfile if possible) 2. Verify that it works as expected: Publish a package that has a shrinkwrap and depends on an older version of a module, install it globally using npm, and ensure the old dependency version is installed rather than the latest version matching the semver range 3. Verify it works for transitive dependencies too If I remember correctly, shrinkwrap doesn't handle optional dependencies well, and has a bunch of other issues (which is the whole reason Yarn has its own lockfile format). Is that still the case with newer npm versions? bundledDependencies sounds interesting, but we'd still need to update the build scripts to handle it. Would you like to send pull requests for this?

[forivall]

Yes, I'd be open to writing a pull request that makes the installation of yarn use the features of npm that allow installation to be deterministic. However, I'd like this small fix to the documentation (which I've revised to be less substantial) to be considered first.

On points 2 and 3, i would just be able to use the shrinkwrap tests that are in the npm test suite, but substitute in the yarn generate-lock-entry and yarn.lock -> shrinkwrap conversion.

[Daniel15]

However, I'd like this small fix to the documentation (which I've revised to be less substantial) to be considered first.

Your updated text looks great. Please just update "Yarn" to have an uppercase "Y" and I think it's good to go. Thank you!

[forivall]

Since this PR is closed, I've made that capitalization fix at #485. Thanks!

[gaearon]

I just wanted to chime in to say we take these issues seriously, and want to avoid any kind of misrepresentation of how Yarn compares to npm.

I submitted an additional PR in #518 that I hope helps further rectify it. If you find any additional places where you feel npm behavior is misrepresented, or one could imply that, please let us know and we’ll be happy to fix those up.

Thanks! ❤️