Open snopeks opened 8 years ago
Three thoughts:
^
ranges are default, and some more conservative folk use ~
. Either picks up patch releases, including doc-only patch releases. npm i
is unlikely to duplicate a package with versions only a single patch version apart.npm update-readme
wouldn't affect the README clients receive in tarball on npm install
. I fully expect most folks peruse READMEs on npmjs.com and github.com, rather than less
like this old fogey. But mismatches could confuse, and potentially confound if, say, the README online has license information and the README in tarball does not.Some really valid points there. I ignorantly assumed that because I consume the README via the registry that everyone else does this too.
Seems like you killed that idea quick smart! 😃
@mrvautin ideas can't be killed, and I wouldn't try if they could! God help anyone who gives me the last word on matters npm-ish.
As for README
s on npmjs.com, again, I think I'm in a small minority that looks in node_modules
first. If it were a simple matter of pleasing either browser-folk or pager-folk, I'd expect npm CLI and npm, Inc. to favor browser-folk.
@kemitchell I hope you didn't take offence. I was referring to your points being a very good reason to leave it the way it is. The risk of doco mismatch probably outweighs the convenience.
I think a fairly strong case could be made for a update-readme
command which would follow @kemitchell's reccomendation of not updating the tarball, but updates the website display. I often release x.x.1
versions just to update formatting or typo's in the readme.
Based on user feedback, we're hearing it would be nice for users to republish/refresh their readme without bumping their package version.
See example feedback: https://twitter.com/mrvautin/status/767184966564274176
Thoughts?