This also means that bash (for example) scripts that use NPM won't be screaming a ton of output through my SSH terminal. It may be necessary if there were a setting to allow users to default to -verbose, though. This means that npm's default behavior should actually be the behavior of -silent, and -silent is not necessary because it would be the default behavior. If it breaks, then it should let you know that it broke. In general, if a tool works and the goal of the program isn't specifically to send something to standard output (EG, ls, ps, cat) then it shouldn't output anything there unless specifically requested by the user. The unix philosophy suggests that "When a program has nothing surprising to say, it should say nothing." I've personally always found it peculiar that NPM does not respect this. I think that it's worth noting that a related issue here is that the default behavior should be -silent. I'd rather not mess with the internals of the npm command cache. If there's a simpler way to call npm.view and also pass in "true" for the silent parameter, that would be helful. I could refactor some of these "output from API" as a pull-request. I understand many of these functionalities are inherently output-oriented, and generally should output information, but that should be the reponsibility of the CLI layer. In my case, I'm calling npm.view programmatically, and I'm getting the console.log of the package info, though I don't want to display it. Other functions that use a second, un-passable "silent" parameter: The code handles this gracefully by defaulting silent to false in all cases. Once example is npm.view, which has 3 parameters in the signature, but the command-line interface, htrough the npm.commandCache always sends 2 parameters: args and cb. This may be slightly off-topic, but there are a few npm commands that use console.log, which bypasses the npmlog and -loglevel functionality.
0 kommentar(er)
