verbosity: levels 1 and 2 are documented/used but behave the same

[ricardo-devis-agullo]

Summary

Registry verbosity is documented and used as a multi-level setting (0 / 1 / 2), but the implementation effectively treats it as a boolean: any non-zero value enables the same logging.

Docs describe:

Level	Intended meaning
0	Silent (default)
1	Basic logging
2	Detailed / debug logging

Reference: Registry configuration – verbosity and examples that set verbosity: 1 vs verbosity: 2 (e.g. local/dev and storage debugging).

Actual behavior

All checks are truthy / boolean coercions — nothing branches on >= 2 or === 2:

1. HTTP request logging — enabled when options.verbosity is truthy:

if (options.verbosity) {
  adapter.enableLogging({ /* ... */ });
}

2. Startup logger — options.verbosity ? console : noop

3. Storage adapters — verbosity is forwarded into storage options and used as:

const cache = new Cache({
  verbose: !!conf.verbosity,
  // ...
});

So 1 and 2 produce the same runtime behavior today.

Why this matters

• Config examples and env-specific presets (development: 2, staging: 1, production: 0) imply a real gradient that does not exist.
• Operators may raise verbosity to 2 expecting more detail and get none.
• Type/docs say “level” but the code path is on/off.

Proposed options

1. Document reality — state clearly that any verbosity > 0 enables the same access/process logging (and storage cache verbose mode), and treat 1/2 as synonyms until real levels exist.
2. Implement real levels, e.g.:
   • 0 — silent
   • 1 — HTTP access logs + high-level registry messages
   • 2 — above + storage/cache debug (and optionally other debug sinks)
3. Simplify the API — switch to boolean (or verbose: boolean) and migrate docs/examples off numeric levels.

Related

• Default in options sanitiser: missing verbosity → 0
• oc dev hardcodes verbosity: 1
• Storage adapters coerce with !!conf.verbosity (oc-s3-storage-adapter, oc-gs-storage-adapter, etc.)

[ricardo-devis-agullo]

do we have enough logs for splitting into levels or should we just keep it a boolean and change the docs to reflect this?