UX Bug: npm build doesn't run build script in package, instead gives warning

Version: v11.14.0
Platform: MINGW64_NT-10.0 [Windows 10 Pro 1809]

There is a user experience issue with how “scripts” work and run. You have start and test which work and operate differently than the rest.

In the default package.json created by many tools it creates a start, build and test script. The start and test always seem to work fine, however the build one never does. It gives a warning:

npm WARN build npm build called with no arguments. Did you mean to npm run-script build?

Also when I try to add build2 or something it never finds it. when I run “npm build2”. So and having to type "npm run " for some scripts and just “npm <script” for others is annoying.

Why can I run start and test scripts without the run flag and all others require it? I can do npm run start and npm run test so why are those two special. It makes it more complex when in tutorials that have to go back and forth. This inconsistency is very annoying. Can you make it require run for all or make look for scripts for all of them?

The easiest thing to do would be to require RUN for start and test then all scripts work and operate the same. Having some be different than others is bad user experience which is bad for new users.

(Reports to #bugs should use the template which includes extra information like the npm version you are running and platform you are on. I think this belongs in #ideas and moved it, and suggest you therefore change the title to match the idea rather than the problem.)

I stumbled over the same thing early on with especially start, and expecting other run-scripts to run same way. I decided the best way to think about it was that “npm run-script start” is the real command and “npm start” is a convenience shortcut provided only for the most common scripts. I and one of my coworkers always use a long form in our instructions (e.g. “npm run start”) so that less experienced users don’t see two styles of script instructions.

You might like to comment on this related idea:

You can do what you wish however this is a User Experience BUG. Feel free to change anything you want. I provided the NPM version and Platform details as the first two lines.

So I know that if I use “RUN” I can run all the scripts and get into the habbit with START and TEST however that is bad for the users as not one single tutorial new users use teach this. They just say npm start and npm test, and then ng build etc. So they side step the issue. If NPM just removed start and test and forced it to be npm run start and npm run test then the UX Bug is fixed, or they could allow scripts to be run just like start and test.

The fact that it says the warning and how to correct it when you type NPM BUILD is a sign of a UX problem as they clearly know what people are EXPECTING to occur and instead of it working as expected they put a warning message telling you how to get what you are expecting. As NPM BUILD does nothing but spit out this warning for me at least. It has never done anything else.

As for calling it a short cut for the most common scripts I would say BUILD should be more common than start and test. Again User Experience Bug. CLI’s have users and can have UX bugs just like any client with a GUI. The issues for them should be managed and triage just like any other BUG. But NPM can do what ever process they want however out of principle I cannot change the title of this bug to state it is not a bug.

You can do what you wish however this is a User Experience BUG. Feel free to change anything you want. I provided the NPM version and Platform details as the first two lines.

I know that if I use “RUN” I can run all the scripts and get into the habbit with START and TEST however that is bad for the users as not one single tutorial new users use teach this. They just say npm start and npm test, and then ng build etc. So they side step the issue. If NPM just removed start and test and forced it to be npm run start and npm run test then the UX Bug is fixed, or they could allow scripts to be run just like start and test.

The fact that it says the warning and how to correct it when you type NPM BUILD is a sign of a UX problem as they clearly know what people are EXPECTING to occur and instead of it working as expected they put a warning message telling you how to get what you are expecting. As NPM BUILD does nothing but spit out this warning for me at least. It has never done anything else.

As for calling it a short cut for the most common scripts I would say BUILD should be more common than start and test. Again User Experience Bug. CLI’s have users and can have UX bugs just like any client with a GUI. The issues for them should be managed and triage just like any other BUG. But NPM can do whatever process they want however out of principle I cannot change the title of this bug to state it is not a bug.

WOW the Delete on this “community” is horrible and trying to fix a post to be a reply is horrible.

You might have missed it, but I was agreeing with you that it is a source of confusion for new users.

(Note: I don’t work for npm, just help out on the forum. I’ll leave this under #ideas as I still think it is the place it is most likely to be taken into consideration.)

I didn’t miss anything, as you only partially where agreeing so I was making sure it was clear what the BUG is. As UX Bugs are still bugs despite that some people don’t think they are. As you only agree it is confusing not that it is a bug. And it never crossed my mined about who you work for, just that you are clearly a moderator of some kind as you had the ability to change and move posts.

So if NPM policy is that there are no such thing as UX Bugs and all UX “issues” are just “ideas” (aka Feature Requests) then so be it. I can move on and not bother them about other UX bugs in the future as that is just hiding the problem.

Any company or organization that chooses to classify user experience defects/bugs as feature requests is one that doesn’t really care about their users.

Tagging this as #ideas doesn’t mean we value it less; there are a bunch of ideas more important than some of the bugs we get. The bug vs idea is simply a distinction of whether we need to specify new behavior. In this case the code is behaving like intended. Although it may not be the best behavior, we’d need to specify new behavior, and that requires some talking. That’s what #ideas is for, while #bugs is mostly for determining the reason the code doesn’t behave as specified.

As for the confusing behavior of npm build:

  1. One thing’s for sure: we can’t just make npm build a shortcut for npm run build, because it already does something different. We could make it a breaking change etc., but there are easier fixes in my opinion.
  2. For example, we could, as you propose, use the explicit run-script variants of start and test in guides as to not confuse new users. The only npm guide with those that I found is Docker and private modules, so that shouldn’t be too much work.
  3. Assuming new users have the proper guides, I think it’s fine to keep the aliases for users more comfortable with the CLI.
  4. The Yarn CLI actually allows users to leave out the run-script part, provided the script doesn’t have the same name as an existing command. In my opinion, this is more confusing UX, because if they introduce a new command older code may break.
1 Like

Yes, as @larsgw points out, “bug” vs “idea” is not a value judgement; what you’re describing is a breaking change, and (for better or worse) it’s behaving as intended today. That intent may be mistaken or bad, but the program is faithfully implementing it.

I think we could probably remove the user-facing npm build command, as i don’t think many people use it or even know it exists. It’s really an internal function more than anything else. At that point, adding build as a top level script alias, or making any unknown command matching a run script an alias (like yarn does) would solve the op. But that would take some work, and a discovery process to ensure we’re minimizing breakage to existing use cases.

I’m torn on whether it’s better for unknown commands to run scripts like yarn does. It effectively makes any new command a semver major change instead of semver minor, since it will always remove a potential run script alias. But it is a common user expectation, and I can see the value in it.