allow npm pack to work without a package version

[quantizor]

I'm opening this issue because:

• npm is crashing.
• npm is producing an incorrect install.
• npm is doing something I don't understand.
• npm is producing incorrect or undesirable behavior.
• Other (see below for feature requests):

What's going wrong?

When running npm pack on a package.json scope that does not have an explicit version number, the command fails with:

npm pack package.json requires a valid "version" field

supporting information:

• npm -v prints: 6.1.0
• node -v prints: v8.11.2
• npm config get registry prints: https://registry.npmjs.org/
• Windows, OS X/macOS, or Linux?: macOS

What problem is the change intended to solve?

npm link often causes undesired effects because devDependencies are not uninstalled in the linked package. npm pack is a way to get around this by making one-off versions of packages for local installation and testing.

However, npm pack requires a version field to be present in the package. I think this should be made optional. A few cases where a version field would not be present in a module scope:

• If using semantic release without commitback by CI
• A project you're playing with locally but not ready to formally publish yet
• A project not meant to be installed from the NPM registry, but instead via some other hard-coded means like a git branch, etc

Is the absence of this feature blocking you or your team? If so, how?

This isn't a blocker since a version field can be added ad-hoc and removed before committing back to source control. However, it's also one more thing to keep track of.

Is this a feature you're prepared to implement, with support from the npm CLI team?

I could, sure.

[legodude17]

Why wouldn't you have a version field? When would it actually hurt to have it?

[quantizor]

See the "What problem is the change intended to solve?" for that answer.

[legodude17]

If using semantic release without commitback by CI

Why wouldn't it have a version here?

A project you're playing with locally but not ready to formally publish yet

There is no harm adding a version here.

A project not meant to be installed from the NPM registry, but instead via some other hard-coded means like a git branch, etc

Same as above.

I consider having a version field to be the default, and only not have one if having one would cause problems.

[quantizor]

Why wouldn't it have a version here?

If you don't want semantic release to be able to commit back to your repo, the other way it calculates version is to look at some combination of what the highest version in NPM and/or what version tags are in the repository.

There is no harm adding a version here.

There is if you are using this setup and don't want your CI to be committing back to your source repository.

I consider having a version field to be the default, and only not have one if having one would cause problems.

That may be your personal workflow, but it isn't the only one.