Error: package.json requires a valid "version" field

[semantic-release]

Error: package.json requires a valid "version" field

[travi]

fair enough. thanks for talking through it with me. knowing more detail helps me take further steps to ensure i'm doing the right thing. even found a new tool to help automate this a bit further :)

[gr2m]

This seems to be introduces by the patch in #22.

I don’t quite understand why yet, can you elaborate?

Using a placeholder like 0.0.0-development as I see it in this repository solves this, but is this actually the intended usage

We use the 0.0.0-development version placeholder to access that exact issue

[RiftLurker]

Prior to the patch the version would get added to the package.json regardless the presence of the version property. Since then the version is only replaced, requiring it to exist beforehand.
More specifically I want to know whether semantic-release expects you to use a placeholder version or manage the version in any case.

[gr2m]

semantic-release does not require the placeholder version to be set. We recommend to set it so that you can install a dependency directly from a github repository

[RiftLurker]

Thank you for the clarification. I guess this can be classified as a bug then, because publishing is not possible anymore after #22 when the version is not set.

[gr2m]

The version should have been previously calculated to the actual version that semantic-release will publish with to npm. @pvdlg knows the details on how that works better.

Can you link to the project where you run into this problem? If you can’t, did you set any custom configuration? What semantic-release version are you using?

[RiftLurker]

The version was calculated correctly, but never added into the package.json. I was able to observe this in https://github.com/PostCrafter/open-screeps/tree/8abf45a1fd880e2d490c31637041afeb997aab15/src/is-room-visible using [email protected] and semantic-release/[email protected].
Even though I'm also using semantic-release-monorepo I was able to track this down exactly to the changes made in #22.

[pvdlg]

Before #22, the version was indeed added if it was missing, but that wasn't really intentional. The version property is required in package.json per npm doc. So it need to be set, for example with 0.0.0-development. If you want to have the actual last version released in the package.json in your repo you can use the git plugin.

[RiftLurker]

Thank you for clarification, I'll see whether I will commit the actual version into git or use a placeholder version as I do right now.

[travi]

i just ran into this as well while updating one of my packages to the latest semantic-release. I do normally set the version to 0.0.0-semantically-released to remove the npm warning, but must have missed this particular package. Adding it did get me past the error and allowed sucessful publsihing.

However, I think I'm with @PostCrafter's original thoughts on this. Since the version is only really required when publishing, the semantic-release still suggests that this will be handled for you and that you don't need to worry about the version within your repo.

Automatically adding the version when missing seems more appropriate to me than erroring in this case.

[pvdlg]

The wording of only really required when publishing can be improved indeed.

The actual version number of the release (like 1.0.0) is only required when publishing (so the npm registry can read it and save the new version). However the version key in the package.json in always required other the package.json is considered invalid.

You can try out a package.json with a missing version key on http://package-json-validator.com

[travi]

Is being that strict actually valuable though?

A version doesn't make any sense for an application, for example, but it still uses a package.json for tracking dependencies, etc. Sure, you could define a version, but when following continuous deployment, the only realistic version would be the git hash, so there is little value in capturing it (especially since the hash isnt calculated until the commit is made).

EDIT: I suppose I normally mark private: true for applications, so maybe that is the correct response to that situation. I can't really argue against strict rules that can be validated against, but most projects don't do so, so this type of change just seems a bit much.

If this does stay as an error, do you happen to know of an npm cli tool that would perform the same validation as what you linked to above? I could see value in building that type of check into my project scaffolder to avoid hitting this type of error in the future.

EDIT 2: I found the link to the github repo for the validator and it looks like it provides a cli. I'll take a look and see if it makes sense to include in my setup.

[pvdlg]

This is really a matter of compromises. This issue appeared with #22 that preserves the package.json format by updating the version value rather than parsing the JSON to a JS objet, setting the version, stringifying and saving.

As the package.json is published and can be pushed to the repo with the git it's important to preserve the formatting. It's arguable if pushing the updated package.json to the repo is a good practice or not, but it was by far the most requested semantic-release feature (See semantic-release/semantic-release#211 semantic-release/semantic-release#497, semantic-release/semantic-release#422 and several other duplicates).

As the npm specs mention that the version key is mandatory and preserving the package.json format is necessary for a wildly requested feature, the compromise was to implement #22 and #28.

If this does stay as an error, do you happen to know of an npm cli tool that would perform the same validation as what you linked to above? I could see value in building that type of check into my project scaffolder to avoid hitting this type of error in the future.

Yes the same tool offer a CL

[pvdlg]

Always a pleasure :-)