Release as often as you want, so long as you follow SemVer (semver.org). NPM has assumptions built in that package authors will follow SemVer; particularly in the way it auto-updates when people specify dependencies with ^, ~ or .x notation.
So if you release ten updates, each with a bugfix version increment (1.0.1, 1.0.2, etc) and no breaking changes, people consuming your package who have opted in to auto-update patch versions get the fixes automatically. That is totally cool.
If you _add features _without any breaking changes, then increment the minor number, eg. 1.2.0 -> 1.3.0. Also cool. Do this as often as you like.
If you make a breaking change, update the major version. 1.x -> 2.0.0. While you wouldn't want to do this constantly (it's a bit annoying), it's still legitimate versioning. If you have lots of breaking changes, those I recommend you batch into a single release with plenty of documentation and an upgrade guide.
What would be totally wrong... would be releasing breaking changes under the wrong version number. That is if your live version is 1.2.3 and you break your API in 1.2.4 so peoples code stops working - expect people to be really upset. Release you breaking change in 2.0.0 and all is well.
Do not be afraid to increment your numbers! There is no actual harm in updating numbers. Remember you can release as many as you want, 1.2.45 is entirely legit if you release 45 bugfixes on top of 1.2 (although it's unusual to have that many updates in a 1.0+ or non-beta version, it's legit numbers).
For more of my opinions on SemVer, have a look at webdirections.org/blog/video-ristretto-ben-buchan… :)