-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
doc: add preferDev and update preferGlobal #143
Conversation
doc/files/package.json.md
Outdated
@@ -733,12 +733,16 @@ The host architecture is determined by `process.arch` | |||
|
|||
## preferGlobal | |||
|
|||
**DEPRECATED** | |||
Inform that this package is usually installed globally. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would this no longer be deprecated? I can’t think of any reason that a package should decide that it’s preferred globally; that always depends on the installer’s use case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're having preferDev
as guidance towards devDependencies
, I though it might be weird if preferGlobal
had the same effect but was considered deprecated. I realise installing globally isn't a meaningful distinction given npx
and npm run-script
, but I meant it more like a property saying "this is a CLI".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think preferDev makes perfect sense (and preferPeer, tbh) because the action they recommend is a best practice for that package. preferGlobal is, at best, recommending a bad practice that’s blessed by that package’s authors.
db63b89
to
b09bc8c
Compare
06cdf5b
to
f957798
Compare
896149d
to
31718e7
Compare
Unfortunately |
See https://npm.community/t/4769