Opentelemetry-js: Make package structure more consistent

[danielkhan]

Triggered by #389 @mayurkale22 and I started a discussion on the overall consistency of our package naming and we came up with the following scheme:

@opentelemetry/sdk-base
@opentelemetry/sdk-tracing (basic tracer - mainly for manual operations)
@opentelemetry/sdk-metrics
@opentelemetry/sdk-node (sdk-base + sdk-tracing + sdk-metrics)
@opentelemetry/sdk-web (sdk-base + sdk-tracing + sdk-metrics)

@opentelemetry/sdk-metrics can later be appended by a platform if we need a specialization which would lead to@opentelemetry/sdk-metrics-node and @opentelemetry/sdk-metrics-web

Linking the very first discussion on naming #6 for backreference.

Please add your thoughts as this needs to be done before we can cut the release.

[mayurkale22]

@OlivierAlbertini @vmarchaud @rochdev @hekike @draffensperger @bg451 @markwolff @obecny @dyladan WDYT?

[mayurkale22]

Mapping between old package name to new name.

Old Name | New Name
----------| --------------
@opentelemetry/sdk-base | @opentelemetry/sdk-base
@opentelemetry/tracer-basic | @opentelemetry/sdk-tracing
@opentelemetry/node-sdk | @opentelemetry/sdk-node
@opentelemetry/tracer-web| @opentelemetry/sdk-web
@opentelemetry/sdk-metrics | @opentelemetry/sdk-metrics

[obecny]

I wonder if we even need sdk-* ? I agree to remove basic it might means different things for different people.
I would go even simpler:

@opentelemetry/base
@opentelemetry/tracing (basic tracer - mainly for manual operations)
@opentelemetry/metrics
@opentelemetry/node (base + tracing + metrics)
@opentelemetry/web (base + tracing + metrics) 

and the reason is that we already have a word opentelemetry in front of them

[dyladan]

I am trying to imagine what using the final product is going to look and feel like to end users. In my mind there are a few types of users:

1. application owners that want to trace their apps (little to no code modification)
2. library owners that want to build in OpenTelemetry support directly rather than relying on plugins (heavy code modification)
3. OpenTelemetry plugin developers (including contrib)
4. OpenTelemetry "core" developers

They have different uses for packages and will need to use different packages to fulfill those needs. I would describe app owners as consuming OpenTracing, lib and plugin devs as developing software using OpenTelemetry, and core devs as building OpenTelemetry. I would _typically_ think of "Library X SDK" as a tool for developing software that interacts with "Library X", not simply a consumer. As an example think of the jdk vs jre. The jdk is used to develop java programs, but if you just need to run one you only need the jre. With these things in mind I would propose the following names:

Old Name | New Name
-- | --
@opentelemetry/node-sdk | @opentelemetry/node
@opentelemetry/tracer-web | @opentelemetry/web
@opentelemetry/sdk-base | @opentelemetry/sdk-base
@opentelemetry/tracer-basic | @opentelemetry/sdk-tracing
@opentelemetry/sdk-metrics | @opentelemetry/sdk-metrics

[bg451]

Do we want more fine grained package naming for web code to reduce bundled code size? That way if someone is using only the metrics implementation, they don't have to also import the tracer code.

[danielkhan]

As mentioned, this can be done as needed. We won't publish metrics with the alpha so we can decide as we build out metrics.

[rochdev]

I tend to agree with @obecny. The entire repo is basically the SDK, no need to specify that at every package really.

[rochdev]

Do we want more fine grained package naming for web code to reduce bundled code size?

I think there should be more fine-grained packages, but there should still be the aggregate that is bigger but easier to install to get started.