Add note about why installing via npm is not recommended

[Daniel15]

I tried to be as neutral as possible while writing this, let me know if it doesn't make sense.

[jamiebuilds]

The only really convincing bit here is the security check, I would simplify it to just that.

[palmerj3]

Is this true? Fairly certain NPM DOES do shasum validation - https://github.com/npm/npm/blob/latest/lib/cache/add-remote-tarball.js#L86

[Daniel15]

Hash verification is not the same. It doesn't verify who uploaded the
package or that it's actually a legitimate release, it's just a hash of the
contents. Additionally, npm uses SHA1, which is not considered secure.

[Daniel15]

I should probably also mention the fact that dependency versions are locked down with all other installation methods, so things like yarnpkg/yarn#2072 are avoided.

[wjordan]

I should probably also mention the fact that dependency versions are locked down with all other installation methods, so things like yarnpkg/yarn#2072 are avoided.

@Daniel15 floating dependency versions are not required in package.json, it's just an npm install default. You really should lock dependency versions in package.json, if its important to keep yarn's correct behavior strictly guaranteed across all installation methods. To lock down dependency versions, just update the package.json to specify exact versions of your project's dependencies (e.g., "node-emoji": "1.4.3") rather than ranged versions ("node-emoji": "^1.0.4"), then adjust dependency versions in a controlled manner if/when needed (e.g., using npm outdated).

[Daniel15]

You really should lock dependency versions in package.json

That won't lock transitive dependencies. Even if we depend on an exact version of package Foo (say, version 1.2.3), Foo could depend on ^1.0.0 of some other package (or even *, meaning any version).

Locking (including transitive dependencies) can be done with npm shrinkwrap, but apparently it doesn't handle optional dependencies correctly

[palmerj3]

@Daniel15 you should be able to do npm shrinkwrap --no-optionals to make a shrinkwrap that doesn't contain optional dependencies.

[Daniel15]

But then I guess the problem would be that the optional dependencies don't have their version numbers locked... I guess it's better than nothing. Sent from my phone.

…

On Dec 3, 2016 5:48 PM, "Jason Palmer" ***@***.***> wrote: @Daniel15 <https://github.com/Daniel15> you should be able to do npm shrinkwrap --no-optionals to make a shrinkwrap that doesn't contain optional dependencies. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#291 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFnHXrEVoF6zs3NwujPEkyGV-zyYiaEks5rEhv7gaJpZM4K-miP> .

[palmerj3]

Optional deps, by definition, shouldn't be required in order for a project to function :) If they are then that's a much bigger problem.

[jamiebuilds]

Yeah, but there's a difference in them not being there and them being there and being broken.

[Daniel15]

@thejameskyle - hopefully it's good now, let me know what you think 😃