Let's make policy for: Warning of potentially dangerous but supported behavior & for deprecation

[iarna]

Two separate things that often get mixed up together:

1. How do we warn about potentially dangerous or incorrect, but still supported behavior? This is things like, missing fields in the package.json, values that will probably be wrong, but aren't necessarily, like bin entries that don't exist at publish time. These are related to validation failures, but aren't ever fatal.
2. If we are going to eventually remove a feature, how do we flag it for deprecation.

Historically, for both of these, we would just log.warn a message. But npm@3 brings the ability to attach warning or error messages to a node on the tree, which will then be collected after your action and printed out. This was done primarily to make results more visible– they show up after all of the status messages from an install, but it has many benefits for programatic use as well, as you can easily capture or ignore warnings this way.

[othiym23]

This needs a spec document that the team can sign off on describing the desired policy around deprecation and displaying deprecation information, and that spec effort should be coupled with a project to square up how that works within npm currently to follow the spec. This is something the team needs to tackle, and it's in scope for the next year or so.

[npm-robot]

We're closing this issue as it has gone thirty days without activity. In our experience if an issue has gone thirty days without any activity then it's unlikely to be addressed. In the case of bug reports, often the underlying issue will be addressed but finding related issues is quite difficult and often incomplete.

If this was a bug report and it is still relevant then we encourage you to open it again as a new issue. If this was a feature request then you should feel free to open it again, or even better open a PR.

For more information about our new issue aging policies and why we've instituted them please see our blog post.