Consider making internal SDK components private

[dyladan]

Currently we export a lot of functions, types, objects, and classes from our core packages that we consider to be internal. This leads people to depend on these components which we do not recommend (example: https://github.com/prisma/prisma/blob/9c6e80e6fadc3068a54bc6cbff2edb218e88d345/packages/engine-core/src/tracing/createSpan.ts). As much as possible we should encourage users to use the API interfaces only.

This could be done by making them private, making the constructors private, or making all properties not included in the interface private (maybe there is some way to exclude some properties from the published types while keeping them internally?)

non-exhaustive list:

• SDK Span and Tracer
• SDK Meter and Metrics
• TracerProvider (still need a way to configure it though)
• Everything in core package

TODO:

• evaluate use of these components in tests in both core and contrib
• see if dd-trace is using these
• see if honeycomb distro is using these

[Flarna]

We could export interfaces instead classes where possible. This has the additional benefit that typescript doesn't complain about incompatible types just because private fields differ.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[MSNev]

related #4185

[JamieDanielson]

Planning for SDK 2.0...

• SDK Span and Tracer is done.
• SDK Meter and Metrics is already private.
• TracerProvider will stay as-is.
• Everything in core package is done.

Will double check on open issues to confirm this can be closed

[pichlermarc]

A summary:

• SDK Span was removed in refactor(sdk-trace-base)!: remove Span class from exports #5048
• SDK Tracer was removed in feat(sdk-trace-*):! drop unintentional/unnecessary exports #5405
• We did not remove TracerProvider as it would have massive impact on end-users, but that's partially tracked by the plan proposed at [all] limitations of our type exports and proposed ways forward #5283 which will see us gradually introducing factory functions as an alternative to constructors. Constructors will be deprecated and eventually the class exports will be removed in 3.0, leaving only interfaces and factory functions.
• The core package changes are tracked in [core] review and remove unused and deprecated exports #5172 - we did not get rid of everything, but we removed a large chunk of exports. Removal of getEnv() will further reduce API surface [core] make browser-implementation of getEnv() return only defaults, getEnvWithoutDefaults() an empty object  #5217

[pichlermarc]

Closing this as we have plans forward for everything that was not completed in SDK 2.0