[RRFC] Clarify the behavior and use cases of `licenseText` field

[haoqunjiang]

Motivation ("The Why")

We are encountering this issue in Vite: https://github.com/vitejs/vite/issues/6210

In summary:

• Background: Vite bundles most of its dependencies with Rollup. Therefore, its LICENSE.md includes all the licenses from those bundled dependencies.
• The Current Behavior: We noticed that the NPM registry has a licenseText field that contains all entire content of LICENSE.md of each version in the package metadata (https://registry.npmjs.org/vite). This makes the Vite metadata grow very fast.
• The Unexpected Outcome: Though npm install isn't affected by this field (licenseText field isn't included with the Accept: application/vnd.npm.install-v1+json request header), this issue becomes a concern when the user is using a private registry. Because a private registry server has to fetch the full metadata from the upstream NPM registry. With this field, it soon becomes an unexpectedly large amount of metadata even for a medium-sized package like Vite.

Example

curl -i https://registry.npmjs.org/vite | head -n 10

HTTP/2 200
date: Tue, 21 Dec 2021 08:29:36 GMT
content-type: application/json
content-length: 32718430
cf-ray: 6c0fbe609d526e2b-HKG
accept-ranges: bytes
age: 160
cache-control: public, max-age=300

We can see current metadata of vite has a content size of 31MB and is still increasing rapidly along with new version publishes.

How

Current Behaviour

The NPM registry has a licenseText field in the package metadata, which may become very large. Yet there is no documentation available for what it does and how it is generated.

Desired Behaviour

1. Document the existence of the licenseText field, so that package authors can be aware that too big a LICENSE file could affect the package metadata size (hopefully before it's too late);
2. Document the algorithm to generate the licenseText field, so that package authors can find a way to circumvent the above-mentioned problem, to control the growth of the package metadata size.
3. If possible, make this field optional
   • so that downstream registries can safely skip this field when syncing with the official registry, reducing the network payload
   • so that we can reduce the metadata size of Vite, even though the previously published versions already had huge metadata.

References

• https://github.com/vitejs/vite/issues/6210