feat(sdk-trace-base)!: remove BasicTracerProvider#register() to improve tree-shaking

[pichlermarc]

Which problem is this PR solving?

Removes BasicTracerProvider#register(), which in the past has auto-registered a W3CTraceContextPropagator and W3CBaggagePropagator, requiring it being included in bundles even when unused.

NodeTracerProvider#register() and WebTraceProvider#register() still provide the same behavior so impact to end-users should be minimal. Everyone that does not want to use the defaults can now use BasicTracerProvider with trace.setGlobalTracerProvider(), propagation.setGlobalPropagator() and context.setGlobalContextManager() to register, while not including the unused context managers/propagators in their bundle.

Refs #5290

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

• Unit tests

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.95%. Comparing base (7d6e11e) to head (a427fa8).
Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #5503   +/-   ##
=======================================
  Coverage   94.95%   94.95%           
=======================================
  Files         309      309           
  Lines        7924     7931    +7     
  Branches     1606     1604    -2     
=======================================
+ Hits         7524     7531    +7     
  Misses        400      400           

Files with missing lines	Coverage Δ
...elemetry-sdk-trace-base/src/BasicTracerProvider.ts	94.64% <100.00%> (-0.88%)	⬇️
...telemetry-sdk-trace-node/src/NodeTracerProvider.ts	100.00% <100.00%> (ø)

[david-luna]

There are some references to BasicTraceProvider#register() in some README files. Some examples:

• opentelemetry-js/experimental/packages/exporter-trace-otlp-grpc/README.md

  Line 41 in 7d6e11e

  provider.register();

• opentelemetry-js/experimental/packages/exporter-trace-otlp-http/README.md

  Line 85 in 7d6e11e

  provider.register();

• opentelemetry-js/experimental/packages/exporter-trace-otlp-proto/README.md

  Line 40 in 7d6e11e

  provider.register();

[pichlermarc]

There are some references to BasicTraceProvider#register() in some README files. Some examples:

* https://github.com/open-telemetry/opentelemetry-js/blob/7d6e11e02ffc655909b2de4dd6c4fef418c0e979/experimental/packages/exporter-trace-otlp-grpc/README.md?plain=1#L41

* https://github.com/open-telemetry/opentelemetry-js/blob/7d6e11e02ffc655909b2de4dd6c4fef418c0e979/experimental/packages/exporter-trace-otlp-http/README.md?plain=1#L85

* https://github.com/open-telemetry/opentelemetry-js/blob/7d6e11e02ffc655909b2de4dd6c4fef418c0e979/experimental/packages/exporter-trace-otlp-proto/README.md?plain=1#L40

Oh, good catch - I forgot to search for it in the other README.mds. Thanks 🙇‍♂️
Fixed in a427fa8

[david-luna]

I guess BasicTracerProvider wasn't meant to be used by SDK users right? Either they use WebTracerProvider or NodeTracerProvider depending on which runtime they want to do instrumentation. right?

Also I see occurrences in several tests related to exporters and processors. do you think it's okay to use BasicTracerProvider there?

[pichlermarc]

I guess BasicTracerProvider wasn't meant to be used by SDK users right? Either they use WebTracerProvider or NodeTracerProvider depending on which runtime they want to do instrumentation. right?

IIUC it was meant to be used by end-users as an unopinionated minimal implementation of the spec and that WebTracerProvider and NodeTracerProvider would provide some defaults for the specific runtime. So there might be cases where you may want to use BasicTracerProvider if the others give you something you don't want and you'd like more control over how it is used.

For Node.js, NodeSDK has largely surpassed NodeTracerProvider and we keep it mostly for backward compatibility until we have improved NodeSDK's interface to be production-ready.

For the Browser, WebTracerProvider is still a good starting point for now as we don't have a NodeSDK equivalent. Long-term I think we will need to transition these users to BasicTracerProvider as an opinionated SDK will always be at odds with the eventually important bundle-size requirements which make a more complex setup process worth its time. I expect that we will largely tackle this with documentation.

Ideally I'd like to fully replace NodeTracerProvider use by end-users with NodeSDK or its successor equivalent, and WebTracerProvider by BasicTracerProvider or its successor equivalent (ideally just called TracerProvider like the providers in logs and metrics to avoid confusion).

Also I see occurrences in several tests related to exporters and processors. do you think it's okay to use BasicTracerProvider there?

I think that's fine (should be encouraged even). The tests often use the more minimal implementation to maximize compatibility and reduce the chance of internal behavior changes breaking tests.

[pichlermarc]

Ideally I'd like to fully replace NodeTracerProvider use by end-users with NodeSDK or its successor equivalent, and WebTracerProvider by BasicTracerProvider or its successor equivalent (ideally just called TracerProvider like the providers in logs and metrics to avoid confusion).

But that's something for 3.0 and beyond. 🙂