"No license field" and "No repository field" warnings for scoped (private) projects

cli

(Jonathan Felchlin) #1

What I Wanted to Do

Install a scoped (implicitly private) project without setting the license or repository fields and without encountering a warning.

What Happened Instead

Encountered “No license field” and “No repository field” warnings.

$ npm install
npm WARN @myscope/my-project@0.1.0 No repository field.
npm WARN @myscope/my-project@0.1.0 No license field.

Reproduction Steps

  • Create a namespaces project, which is implicitly private.
  • Run npm install in the project root.

Details

Setting "private": true fixes the warning, but then the package cannot be published to the private scope.

npm ERR! This package has been marked as private
npm ERR! Remove the 'private' field from the package.json to publish it.

npm ERR! A complete log of this run can be found in:
npm ERR!     /root/.npm/_logs/2018-10-10T00_22_09_885Z-debug.log

Platform Info

N/A

$ npm --versions
{ '@energysavvy/graphql-js': '0.1.0',
  npm: '6.4.1',
  ares: '1.10.1-DEV',
  cldr: '32.0',
  http_parser: '2.8.0',
  icu: '60.1',
  modules: '57',
  napi: '3',
  nghttp2: '1.32.0',
  node: '8.12.0',
  openssl: '1.0.2p',
  tz: '2017c',
  unicode: '10.0',
  uv: '1.19.2',
  v8: '6.2.414.66',
  zlib: '1.2.11' }
$ node -p process.platform
darwin

(Kat Marchán) #2

See https://docs.npmjs.com/files/package.json#license


(Jonathan Felchlin) #3

I understand how to use the license field, but the license and repository fields should not be required for private packages. The fact that npm install warns that they are not set for namespaced packages, which are implicitly private, is a bug. Explicitly setting the package to “private”: true prevents the warning, but then the package cannot be published, even to a private repository. This is mostly a problem when it comes to the repository field. Given that most private packages don’t rely on npm docs at all, there is no use for the repository field. In fact, setting the repository field in package.json often results in the value becoming out of date when packages are reorganized, which is a common occurrence in many organizations.


(Kat Marchán) #4

Would you be interested in putting an RFC together, and we can have more of a conversation about the implications of this change? The way you put it, it definitely seems worth considering and I think it’s worth thinking harder about.