-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in 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