feat: add @opentelemetry/browser-sdk package

[david-luna]

Which problem is this PR solving?

Follow up on #224. This PR is now targeting a feature branch so we can break down the implementation in smaller PRs and merge it to main once its ready.

Short description of the changes

• add a new @opentelemetry/browser package
• all comment in the prior PR were resolved except feat: add @opentelemetry/browser package #224 (comment)
• for this last comment the package now exports startBrowserSdk function instead of the combine utility. The reason is there is no other use case. Either you start one single SDK or both. The combine function stays internal until we decide to add a third signal (metrics).

This PR aims to define the main API to configure the signals (logs, traces) separate and together. Also it explores on how to provide a flexible way for defaults without having to pay the toll on bundle size.

For those who want to read

Add a new package named @opentelemetry/browser which holds the setup of the different signals separately and provides a main function which composes them together into an SDK interface with stop method.

This approach has taken into consideration that configuring all signals into a single SDK class presents challenges when it comes to tree shaking and bundlers cannot anticipate which modules are going to be used. So the configuration has been split by signal and needs to be imported explicitly by the consumer making easier for bundlers to analyse the code and remove unused modules. The package provides different entry points depending on which signal you want to configure

Subpath	Purpose
@opentelemetry/browser/logs	startLogsSdk — setup logs
@opentelemetry/browser/traces	startTracesSdk — setup traces
@opentelemetry/browser/sdk	startBrowserSdk — setup both

with this approach you can configure a single signal

import { startLogsSdk } from '@opentelemetry/browser/logs';

const logsSdk = startLogsSdk({
  logLevel: 'DEBUG',
  serviceName: 'my-service',
  exportConfig: {
    url: 'https://collector.mycompany.com/v1/logs',
    headers: { foo: 'bar' }
  },
  logRecordLimits: { attributeCountLimit: 128 },
});

or both at the same time

import { startBrowserSdk } from '@opentelemetry/browser/sdk';

const sdk = startBrowserSdk({
  logLevel: 'DEBUG',
  serviceName: 'my-service',
  serviceVersion: '1.0',
  resourceAttributes: {
    'browser.has_speech_recognition': typeof SpeechRecognition === 'function'
  },
  exportConfig: {
    url: 'https://collector.mycompany.com',
    headers: { foo: 'bar' }
  },
  // Optional - logs signal configuration. Default empty empty
  logs: {
    logRecordLimits: { attributeCountLimit: 128 },
  },
  // Optional - traces signal configuration. Default empty empty
  traces: {
    spanLimits: { attributeCountLimit: 128 },
  },
});

Note: the intent is to have all necessary components to start/build SDKs in this package. This PR does not go any further than providing a small API (3 functions) and configurations types for several reasons:

• keep the review scope small so we have meaningful conversations. We can add more components in follow-up PRs also keeping the scope small
• this also enables other contributors to add code to this package so it's not a solo quest but rather a collaboration effort
• IMO as a consequence of the points above the velocity of implementing this package will increase. Also I will not be holding/blocking anything in a huge PR (this is already big enough).

Also this PR targets a feature branch and not main so the package won't be published until the SIG decides it has all it need to be public.

For more details on the package and its design refer to the README.md file of the package.

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

• Unit tests

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[martinkuba]

I wonder if the directory this package is in should be called sdk instead of browser, which does not describe what the package is (even though it maps to the published name, but that has a specific reasoning). We already don't match it, as we have instrumentation directory that contains package called browser-instrumentation.

[david-luna]

I wonder if the directory this package is in should be called sdk instead of browser, which does not describe what the package is (even though it maps to the published name, but that has a specific reasoning). We already don't match it, as we have instrumentation directory that contains package called browser-instrumentation.

If we want to align with the existing instrumentation package then we should:

• change the package name to @opentelemetry/browser-sdk
• rename the folder to sdk

I'm okay with that. I would add a review to the package exports section for better naming. This might look weird

import { strartBrowserSdk } from '@opentelemetry/browser-sdk/sdk';

// rest of the code

[overbalance]

TODO: fix after merge