Skip to content

[BUG] When run script loglevel is ignored unless set to "silent" #3354

Closed

Description

@crystalfp

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Running any script by npm shows a log of the script execution even if it is not an error. For example:

npm run my-script --loglevel error

> my_server@0.19.2 my-script D:\Project
> npx copyfiles --flat client/*.png server/http

The only way to silence the log message is by setting --loglevel silent

The problem is that setting loglevel in .npmrc silences also valid messages from npm. I had to spent too much time to debug why npm was not installing my application. Removing .npmrc revealed a version problem in my packages.

BTW this issue is a re-submission for npm@7 of #2468 for npm@6

Expected Behavior

If it is not an error, nothing should be shown by npm, only the script messages should appear.

Steps To Reproduce

  • Create a directory with a project in it
  • Edit package.json and add script "start": "node -e console.log('Hello')"
  • Run npm start. It shows the log
  • Run npm start --loglevel error. It show the log message, but it should not, it is not an error
  • Run npm start --loglevel silent. No log message.

Environment

  • OS: Windows 10 64bits
  • Node: 16.2.0
  • npm: 7.15.1

Activity

  1. added
    Bugthing that needs fixing
    Needs Triageneeds review for next steps
    Release 7.xwork is associated with a specific npm 7 release
    on Jun 3, 2021
  2. ruyadorno commented on Mar 3, 2022

    @ruyadorno
    Contributor

    hi @crystalfp thanks for taking the time to reporting this, there are a few other loglevel/output issues that this makes me think of that we were currently tackling:

    From my point of view it seems to me that tweaking npm run to only print errors (maybe only print the stderr stream from the child process?) is a reasonable thing to do.

    @lukekarrys I'd love to hear your thoughts on it, I know you've been handling the overall output clean up so this one is a very good one to keep in mind.

  3. added
    Enhancementnew feature or improvement
    Priority 2secondary priority issue
    and removed
    Bugthing that needs fixing
    Needs Triageneeds review for next steps
    on Mar 3, 2022
  4. self-assigned this
    on Mar 3, 2022
  5. crystalfp commented on Mar 4, 2022

    @crystalfp
    Author

    Well, I got into the habit of using always the -s option. So in case of strange behaviors, I simply rerun npm without it. Having a functioning loglevel option (or something similar) that I can put in the .npmrc file and forget it is sure much simpler.

  6. removed their assignment
    on Jul 11, 2022
  7. added
    semver:majorbackwards-incompatible breaking changes
    and removed
    Enhancementnew feature or improvement
    Release 7.xwork is associated with a specific npm 7 release
    on May 11, 2024
  8. self-assigned this
    on May 11, 2024
  9. lukekarrys commented on May 13, 2024

    @lukekarrys
    Contributor

    In bcc781a, this output was moved from stdout to stderr when in --json mode.

    I think this should probably be what happens all the time, but that would be a breaking change. I documented the new behavior with a comment in the code indicating this should be changed in the future. I think these should probably be log messages with a level of info (but maybe still rendered with a > prefix) so they can be hidden with the standard loglevel filters.

    cli/lib/utils/display.js

    Lines 321 to 326 in b54cdb8

    // In json mode, change output to stderr since we dont want to break json
    // parsing on stdout if the user is piping to jq or something.
    // XXX: in a future (breaking?) change it might make sense for run-script to
    // always output these banners with proc-log.output.error if we think they
    // align closer with "logging" instead of "output"
    level = output.KEYS.error

  10. removed their assignment
    on May 13, 2024
  11. lukekarrys commented on May 14, 2024

    @lukekarrys
    Contributor

    I'm going to close this since we wont be tracking it as a bug. Instead it's on the v11 roadmap issue since changing it would be a breaking change npm/statusboard#488

  12. wraithgar commented on Apr 6, 2026

    @wraithgar
    Contributor

    This did not make it into npm 11 but it will be in npm 12. PR is up, it's on the npm 12 roadmap

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Priority 2secondary priority issuecmd:run-scriptrelated to `npm run-script`config:displayIssues dealing with display of data to terminalsemver:majorbackwards-incompatible breaking changes

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions