# opentelemetry-js-contrib holds the community instrumentations the core SDK does not ship > The opentelemetry-js-contrib repository collects community maintained OpenTelemetry JavaScript packages: instrumentations, metapackages, context propagators and resource detectors, each with its own named owners. It is the place to look when a library you depend on needs tracing, and the place where support levels vary package by package. **open-telemetry/opentelemetry-js-contrib** — OpenTelemetry instrumentation for JavaScript modules - Repository: https://github.com/open-telemetry/opentelemetry-js-contrib - Website: https://opentelemetry.io - Stars: 938 · Forks: 728 - Language: TypeScript - License: Apache-2.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-js-contrib ## Everything outside the core API and SDK distribution This repository exists to hold what the core repository does not. The project describes itself as a repository for community maintained OpenTelemetry JavaScript contributions that are not part of the core repository and core distribution of the API and the SDK. That boundary is the whole design. The core project owns the tracer, the SDK and the API surface, and everything else, the pieces that hook a particular framework or a particular logger into those primitives, lives here. The practical effect is that you will see two separate dependency trees in a project that uses OpenTelemetry: the core packages and the contrib packages, and they do not move in lockstep. A team pinning versions has to think about both, and the release notes of each set have to be read separately. ## Four kinds of package, named by prefix The repository organises itself by naming convention, which is the fastest way to work out what you are looking at. Instrumentations carry the instrumentation-* prefix and live under ./packages. Metapackages carry the auto-* prefix, and those are the bundles that pull a set of instrumentations together so you can enable them in one step rather than adding each dependency by hand. Context propagators carry the propagator-* prefix and handle carrying trace context across process or service boundaries. Resource detectors carry the resource-detector-* prefix, and they collect attributes about the entity producing telemetry. The documentation gives the container case as the example: a process running in a container on Kubernetes has a Pod name, it is in a namespace, and it may be part of a Deployment which also has a name, and all three can be included in the Resource. ## Component owners decide, maintainers step back Governance here is decentralised in a way that has direct consequences for a dependent. Each component in the repository is maintained by one or more designated component owners. Unless necessary to resolve disagreements, the javascript-maintainers team takes a more passive role when it comes to maintaining these components. Component owners have the authority to make decisions on implementation and feature requests, and they are assigned the Triager role to manage issues related to their components and are the primary contact for conducting pull request reviews for their components. They are also automatically assigned to pull requests as reviewers. The source of truth for who owns what is the file .github/component_owners.yml. In practice this means a question about one instrumentation is answered by the people named in that file, not by a central team, which is both the strength and the risk of the model. ## Stability level and runtime support are decided per package Two support questions come up immediately when you evaluate a package here, and the answers differ between packages. The first is stability. Stability levels for components in this repository follow the definitions in CONTRIBUTING.md, so the label attached to a package is set by a written policy rather than by feel. The second is runtime support, and here the repository is unusually direct: packages have a variable range of support for Node.JS and browser versions, and that range depends on the activeness of the owners of those packages, the techniques or runtime features used, and in the case of the auto-instrumentations, the supported runtime versions for the underlying package. The last point is the one that bites. An auto-instrumentation inherits the version ceiling of the library it instruments, so a fast moving dependency pulls the whole metapackage's support window down with it. ## Building the workspace with nx and running the test services The repository is a large npm workspace driven by nx, and the scripts in package.json show how the work is run. The whole workspace compiles with a single target: ```bash nx run-many -t compile ``` A full test run uses the same shape, and the package manifest also defines a browser test target, since several packages have to be verified in a browser environment as well as under Node: ```bash nx run-many -t test ``` Some tests need backing services, and those are started and stopped with a Docker Compose file kept under test/: ```bash docker compose -f ./test/docker-compose.yaml up -d --wait ``` The scripts also carry an affected-aware variant for CI, using nx affected so a pull request only runs the tasks for the packages it touches, and a list:affected script that pipes the project list out of the nx graph for reuse. The presence of a test-all-versions target is the more interesting one for a dependent: it runs the test suite against the oldest and newest acceptable dependency versions, which is how the repository checks that its packages survive the range of library versions they claim to support. ## Examples exist for the libraries people actually ask about The examples directory holds runnable starting points rather than only documentation fragments, and the folders that exist show which integrations the maintainers consider common enough to demonstrate. The list includes bunyan, express, redis and web. That set is telling: a logging library, a web framework, a cache client and browser side code, which covers the four categories of instrumentation that most JavaScript services end up needing. The examples also matter for the auto-instrumentations, because they show the wiring pattern between the metapackage and the SDK you already have configured. The repository also keeps an archive/ directory at the top level, which is where retired packages are moved rather than deleted outright, so a dependency you find in the wild may exist there rather than under packages/. ## Where this repository stops and the core one starts The honest boundary is between a community instrumentation and the SDK it plugs into. If you need a new instrumentation for a library, the documentation tells contributors to read the contributing guidelines on adding new instrumentation before opening a pull request, and it points at the fact that vendors and users can also create and use their own instrumentations. That second half is the practical alternative for a team whose dependency has no package here: write the instrumentation yourself against the core API, or use a vendor supplied one. The difference in approach is ownership. A contrib instrumentation carries named owners, a stability level and a stated runtime range, but its dependency versions are pinned to the community release cadence and the release notes live with that community. A hand written instrumentation costs you maintenance but removes the version negotiation entirely. ## Licence, release automation and the pace of the repository The licence field on the repository says Apache-2.0, and the README carries the matching badge. That is the same permissive licence the wider OpenTelemetry project uses, and it places no copyleft obligation on a service that merely depends on the packages. Release handling is automated rather than manual: the repository carries release-please-config.json and a .release-please-manifest.json, so version bumps and changelog entries are produced by tooling from conventional commit messages. Dependency updates run through renovate.json, and the linting and formatting rules are shared across the tree through eslint.config.mjs and prettier.config.js, with knip.jsonc catching unused dependencies. The last push was on 2026-10-19 and the repository is not archived, and the recent release list shows independent releases for separate packages, instrumentation-winston at v0.68.1, auto-instrumentations-node at v0.81.2 and winston-transport at v0.34.0, published on 2026-10-16 and 2026-10-15. Each package has its own version line, which is convenient for pinning and easy to overlook when you track what your service actually depends on. ## Conclusion opentelemetry-js-contrib suits teams that want OpenTelemetry coverage for a third party JavaScript library without writing the instrumentation themselves, and the metapackage route means one dependency brings in many instrumentations at once. It does not suit a team that needs a uniform support commitment across every package, because the runtime support range and the stability level are decided per package by its owners. Before you depend on a specific instrumentation, read that package's README.md and the engines field in its package.json, then check .github/component_owners.yml to see who reviews the code you are about to rely on. ## FAQ ### What is the difference between opentelemetry-js-contrib and the core opentelemetry-js repository? opentelemetry-js-contrib holds community maintained JavaScript contributions that are not part of the core repository and core distribution of the API and the SDK. The core repository owns the API and the SDK itself. ### What is an auto-instrumentation metapackage in opentelemetry-js-contrib? Packages named auto-* are metapackages that bundle instrumentations so a set of them can be enabled together. In those packages the supported runtime versions also depend on the supported runtime versions for the underlying package being instrumented. ### How do I find out which Node.js versions a contrib package supports? Packages have a variable range of support for Node.JS and browser versions. The repository points you to the README.md files and the engines field in the package.json files for the respective packages. ### Who reviews changes to an instrumentation in opentelemetry-js-contrib? Each component is maintained by one or more designated component owners who decide on implementation and feature requests, triage issues, and are automatically assigned to pull requests as reviewers. The source of truth is .github/component_owners.yml. ### What licence does opentelemetry-js-contrib use? The licence field on the repository says Apache-2.0, and the README carries the matching license badge. The licence file is at the top level of the repository. ## Sources - [License: Apache-2.0](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/LICENSE) - [open-telemetry/opentelemetry-js-contrib on GitHub](https://github.com/open-telemetry/opentelemetry-js-contrib) - [Project website](https://opentelemetry.io) - [README](https://github.com/open-telemetry/opentelemetry-js-contrib/blob/main/README.md) - [Releases](https://github.com/open-telemetry/opentelemetry-js-contrib/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/open-telemetry-opentelemetry-js-contrib