🔎 Search Terms

packageId, version, name, required

🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about packageId, version.

⏯ Playground Link

No response

💻 Code

No response

🙁 Actual behavior

packageId is not generated when a name or version field in package.json is missing.

🙂 Expected behavior

packageId should be generated when a name or version field in package.json is missing.

Additional information about the issue

The reason for the behavior today is most likely the original thinking around identifying the right package amongst multiple versions installed in different node_modules. However, the missing name or version fields can not happen with multiple packages installed by npm. Missing name or version fields mean the package is not publishable, so this is a package in the development working tree, likely in a monorepo.

Another reason might have been the assumption that the version field must be present and a string, and as such this might have been defensive programming against invalid input. However, in such a case it would arguably be better to fail loudly instead of returning undefined. More importantly, the missing version field is explicitly allowed by the npm docs.

The silently missing packageId is confusing for consumers of this interface, who might not handle it meaningfully. E.g. api-extractor silently assumes that the packageId is always present (issue)

Consider also that packageId is currently generated if the field exists and is set to an empty string. But handling a missing version field and an empty string differently is arguably not very meaningful, and is quite confusing to the end users.