Deno Support

Are there any plans for supporting Deno runtime? Perhaps it is a bit early to speak of it, however it seems rather possible due to low number of dependencies for opentelemetry implementation. Deno tries to support browser APIs so providing support might be rather easy.

It’s already possible to import some opentelemetry-js libs via skypack, however using require (for instance, for require('lodash.merge') in opentelemetry/tracing and opentelemetry/metrics, opentelemetry/metrics 2 makes it impossible.

Overall seems to be not so many requires:

> grep -r 'require(' packages/**/src/*
packages/opentelemetry-exporter-collector-grpc/src/CollectorExporterNodeBase.ts:      const { onInit } = require('./util');
packages/opentelemetry-exporter-collector-grpc/src/CollectorExporterNodeBase.ts:        const { send } = require('./util');
packages/opentelemetry-exporter-collector-proto/src/CollectorExporterNodeBase.ts:      const { onInit } = require('./util');
packages/opentelemetry-exporter-collector-proto/src/CollectorExporterNodeBase.ts:        const { send } = require('./util');
packages/opentelemetry-exporter-jaeger/src/types.ts:export const UDPSender = require('jaeger-client/dist/src/reporters/udp_sender')
packages/opentelemetry-exporter-jaeger/src/types.ts:export const Utils = require('jaeger-client/dist/src/util').default;
packages/opentelemetry-exporter-jaeger/src/types.ts:export const ThriftUtils = require('jaeger-client/dist/src/thrift').default;
packages/opentelemetry-exporter-jaeger/src/types.ts:export const HTTPSender = require('jaeger-client/dist/src/reporters/http_sender')
packages/opentelemetry-instrumentation/src/platform/node/instrumentation.ts:    const version = require(path.join(baseDir, 'package.json')).version;
packages/opentelemetry-metrics/src/Meter.ts:const merge = require('lodash.merge');
packages/opentelemetry-metrics/src/MeterProvider.ts:const merge = require('lodash.merge');
packages/opentelemetry-semantic-conventions/build/src/index.js:__exportStar(require("./trace"), exports);
packages/opentelemetry-semantic-conventions/build/src/index.js:__exportStar(require("./resource"), exports);
packages/opentelemetry-semantic-conventions/build/src/resource/index.js:__exportStar(require("./ResourceAttributes"), exports);
packages/opentelemetry-semantic-conventions/build/src/trace/index.js:__exportStar(require("./SemanticAttributes"), exports);

However, it demands more effort due to testing in Deno runtime and validating not using any Node-specific APIs.

Do you have any plans or thoughts at the moment?

Thanks!

[legendecas]

Assigning myself as I’m working on non-main-frame-context support on browsers.

[vmarchaud]

Am I correct in understanding that browsers today (and maybe for the foreseeable future) don’t offer a way to maintain context across native async/await, and so there’s no way to update zone.js (or any userland approximation of zones/other constructs that can keep track of timings/contexts across async operations/ticks) to take them into account, so no usage of otel-js (or any similar tooling) will be able to work with them?

Exactly, this is a known issue and i believe the general agreement is to have a system added into EMCAScript but no one had the time/resource to push it through. The last one was actually @legendecas (https://github.com/legendecas/proposal-async-context)

So the workaround for browsers and Deno for now is to avoid native async/await (either by not using it or transpilation). Is that accurate? (or is there some nuance for browsers I’m maybe missing?)

Currently yes, but from the few discussions i have seen in Deno there is interested from the core team for diagostics tooling and context management is the most important thing in event loop runtimes (there is more info in a PR that someone from MS pulled up there: https://github.com/denoland/deno/pull/8209)