{"action":"created","issue":{"url":"https://api.github.com/repos/npm/npm/issues/8617","repository_url":"https://api.github.com/repos/npm/npm","labels_url":"https://api.github.com/repos/npm/npm/issues/8617/labels{/name}","comments_url":"https://api.github.com/repos/npm/npm/issues/8617/comments","events_url":"https://api.github.com/repos/npm/npm/issues/8617/events","html_url":"https://github.com/npm/npm/issues/8617","id":89629423,"number":8617,"title":"Sanity checks on `npm publish`.","user":{"login":"ChALkeR","id":291301,"avatar_url":"https://avatars.githubusercontent.com/u/291301?v=3","gravatar_id":"","url":"https://api.github.com/users/ChALkeR","html_url":"https://github.com/ChALkeR","followers_url":"https://api.github.com/users/ChALkeR/followers","following_url":"https://api.github.com/users/ChALkeR/following{/other_user}","gists_url":"https://api.github.com/users/ChALkeR/gists{/gist_id}","starred_url":"https://api.github.com/users/ChALkeR/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ChALkeR/subscriptions","organizations_url":"https://api.github.com/users/ChALkeR/orgs","repos_url":"https://api.github.com/users/ChALkeR/repos","events_url":"https://api.github.com/users/ChALkeR/events{/privacy}","received_events_url":"https://api.github.com/users/ChALkeR/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/npm/npm/labels/feature-request","name":"feature-request","color":"98DCFF"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-06-19T18:29:33Z","updated_at":"2016-02-19T21:50:54Z","closed_at":"2016-02-19T21:50:54Z","body":"Is it acceptable to block `npm publish` when something is technically fine, but suspicious?\r\nIs it acceptable print non-blocking warnings on `npm publish` for the same reason?\r\n\r\nIs `npm publish` supposed to be used in scripts without extra flags? If yes, then it's probably not fine to block it.\r\n\r\nAn example of blocking would be to ask the user «{something is suspicious}. Are you sure that you want to publish the package? Y/n». If that is inacceptable, is it ok to introduce non-blocking warnings (the package is published, but the user receives a notice in the process).\r\n\r\nSome reasons when the warning would be desirable: when the package size is too big (that's a common mistake to include something that should not be included, see #8339 for details), when the package dependencies are not nice (see #8619 for details), etc."},"comment":{"url":"https://api.github.com/repos/npm/npm/issues/comments/186424541","html_url":"https://github.com/npm/npm/issues/8617#issuecomment-186424541","issue_url":"https://api.github.com/repos/npm/npm/issues/8617","id":186424541,"user":{"login":"othiym23","id":418097,"avatar_url":"https://avatars.githubusercontent.com/u/418097?v=3","gravatar_id":"","url":"https://api.github.com/users/othiym23","html_url":"https://github.com/othiym23","followers_url":"https://api.github.com/users/othiym23/followers","following_url":"https://api.github.com/users/othiym23/following{/other_user}","gists_url":"https://api.github.com/users/othiym23/gists{/gist_id}","starred_url":"https://api.github.com/users/othiym23/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/othiym23/subscriptions","organizations_url":"https://api.github.com/users/othiym23/orgs","repos_url":"https://api.github.com/users/othiym23/repos","events_url":"https://api.github.com/users/othiym23/events{/privacy}","received_events_url":"https://api.github.com/users/othiym23/received_events","type":"User","site_admin":false},"created_at":"2016-02-19T21:50:54Z","updated_at":"2016-02-19T21:50:54Z","body":"> It sounds like what you want is to have some more package lint checks, and to move those into npm itself. I think this would be a useful affordance for a lot of developers, and I also think a great way to figure out what to check would be to put the checks in an external package linter, at least until we have a good idea of what's useful and what's not.\r\n\r\nI still feel that this is the best way to start adding quality and appropriateness checks to the CLI. Build a linter, get some real-world experience with it, allow people to play around with it, and at that point, it could make sense to integrate it directly into the CLI. Given the other things on the CLI team's list of things to do, we're not going to have the resources necessary to deal with this, so I'm going to close it, but that doesn't mean that I don't want linting in the CLI. Please, give it a shot!\r\n\r\nThanks for the proposal, and thanks for your time!"}}