Deno Support

[alexander-bzikadze]

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!

[treethought]

Another thing to be aware of for deno support is the use of XHR. Since deno does not support XHR, when trying to use opentelemetry/metrics via jspm, an error is thrown when creating the request

error: Uncaught (in promise) ReferenceError: XMLHttpRequest is not defined
  const xhr = new XMLHttpRequest();

[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.

[legendecas]

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

[Grunet]

Fwiw I tried taking a stab at adapting one of the browser console exporter examples for Deno Deploy to see how far I could get, and I was actually able to make it through to the end with a minimum of monkey patching.

Here's the Deno Deploy code I used. All of the hacks are just below the imports (the last one was also to get around this Deno Deploy issue)

import { serve } from "https://deno.land/std@0.120.0/http/server.ts";

import { context, trace } from 'https://cdn.skypack.dev/@opentelemetry/api';
import { ConsoleSpanExporter, SimpleSpanProcessor } from 'https://cdn.skypack.dev/@opentelemetry/sdk-trace-base';
import { OTLPTraceExporter } from 'https://cdn.skypack.dev/@opentelemetry/exporter-trace-otlp-http';
import { WebTracerProvider } from 'https://cdn.skypack.dev/@opentelemetry/sdk-trace-web';
import { FetchInstrumentation } from 'https://cdn.skypack.dev/@opentelemetry/instrumentation-fetch';
import { ZoneContextManager } from 'https://cdn.skypack.dev/@opentelemetry/context-zone';
import { B3Propagator } from 'https://cdn.skypack.dev/@opentelemetry/propagator-b3';
import { registerInstrumentations } from 'https://cdn.skypack.dev/@opentelemetry/instrumentation';

//Hacks - start
globalThis.document = {
  createElement: function() { //For this line - https://github.com/open-telemetry/opentelemetry-js/blob/bdb61f7e56b7fbe7d281262e69e5bc8683a52014/packages/opentelemetry-sdk-trace-web/src/utils.ts#L33
    return {
      protocol: ":", //For this line - https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-instrumentation-xml-http-request/src/xhr.ts#L170
    };
  }
};
globalThis.location = {}; //For this line - https://github.com/open-telemetry/opentelemetry-js/blob/main/packages/opentelemetry-sdk-trace-web/src/utils.ts#L424

performance.clearResourceTimings = function() {}; //For this line and Deno Deploy bug - https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/opentelemetry-instrumentation-fetch/src/fetch.ts#L181
//Hacks - end

const provider = new WebTracerProvider();

// Note: For production consider using the "BatchSpanProcessor" to reduce the number of requests
// to your exporter. Using the SimpleSpanProcessor here as it sends the spans immediately to the
// exporter without delay
provider.addSpanProcessor(new SimpleSpanProcessor(new ConsoleSpanExporter()));
provider.addSpanProcessor(new SimpleSpanProcessor(new OTLPTraceExporter()));
provider.register({
  contextManager: new ZoneContextManager(),
  propagator: new B3Propagator(),
});

registerInstrumentations({
  instrumentations: [
    new FetchInstrumentation({
      ignoreUrls: [/localhost:8090\/sockjs-node/],
      propagateTraceHeaderCorsUrls: [
        'https://cors-test.appspot.com/test',
        'https://httpbin.org/get',
      ],
      clearTimingResources: true,
    }),
  ],
});

const webTracerWithZone = provider.getTracer('example-tracer-web');

async function handler(req: Request): Response {

  const singleSpan = webTracerWithZone.startSpan('files-series-info');
    context.with(trace.setSpan(context.active(), singleSpan), () => {
      fetch("https://httpbin.org/get").then((_data) => {
        trace.getSpan(context.active()).addEvent('fetching-single-span-completed');
        singleSpan.end();
      });
    });

  // await fetch("https://httpbin.org/get");

  return new Response("Hello world");
}

console.log("Listening on http://localhost:8000");
await serve(handler);

And here was the console output

{
  traceId: "f720f78470dbc13cd78b90187533bbec",
  parentId: "9244d1764e81faf1",
  name: "HTTP GET",
  id: "5649f9695859d613",
  kind: 2,
  timestamp: NaN,
  duration: NaN,
  attributes: {
    component: "fetch",
    "http.method": "GET",
    "http.url": "https://httpbin.org/get",
    "http.status_code": 200,
    "http.status_text": "OK",
    "http.scheme": ""
  },
  status: { code: 0 },
  events: []
}

And I haven't tried this (yet), but I wonder if a polyfill for XmlHttpRequest for Deno (like this one from deno.land) could be enough to support a normal exporter before standard support arrives.

[vmarchaud]

I think the main thing that will be missing for correct deno support is a correct context manager, the zone start to fail as soon as you use async/await (in your example you use promises so it works fine).
For this someone will need to take a shot at denoland/deno#7010

[Grunet]

I think the main thing that will be missing for correct deno support is a correct context manager, the zone start to fail as soon as you use async/await (in your example you use promises so it works fine). For this someone will need to take a shot at denoland/deno#7010

(Been trying to read around and unpack your insight after confirming it didn't work with async/await...trying to summarize my understanding below)

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?

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?)

(Fwiw it was this github issue for zone.js that helped crystallize things for me a bit more)

[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: denoland/deno#8209)

[Grunet]

It doesn't address the main context management blocker, but in case it's helpful I made a small polyfill for navigator.sendBeacon in Deno, as I noticed that was missing and it was either going to be polyfilling that or XmlHttpRequest in order to get the browser HTTP/JSON exporter to work there.

With that I was able to get a full flow through Deno working, but in a very simple case avoiding the native async/await and zone issues discussed above.

[RichiCoder1]

Worth noting that a second attempt at promise hooks might be landing soon: denoland/deno#15475

[nicolasgere]

promise hooks did land in deno 1.26

[smnbbrv]

@legendecas what is the status of the issue? can we help to get it resolved?

[legendecas]

We have test infrastructures to ensure that the SDK supports environments that are web-compatible (like Deno claims). However, we don't have a test infrastructure to run our tests in Deno to guarantee official support. I've been experimenting with running mocha (the test framework used in the project) in Deno. Due to the incompatibility of ESM resolutions (Deno requires the file extension to be present in the module specifier, like import foo from './bar.js'), Deno can not run existing tests natively.

Even though the promise hooks API is exposed in Deno, the fundamental issue is the lack of the API for proper async context propagation: denoland/deno#7010. I'm still pursuing the standardization of async context in TC39, however, it would be a long task.

[Grunet]

Even though the promise hooks API is exposed in Deno, the fundamental issue is the lack of the API for proper async context propagation: denoland/deno#7010.

Would you be able to expand on this point? I noticed in the Deno PR for promise hooks the author outlined what seemed to be a way to get OTEL-JS working in Deno with the feature in this comment denoland/deno#15475 (comment)

(I'll copy their comment below for better visibility)

I believe this would be an equivalent implementation for Deno:

import { Context, ROOT_CONTEXT } from '@opentelemetry/api';
import { AbstractAsyncHooksContextManager } from './AbstractAsyncHooksContextManager';

interface HookCallbacks {
  init: (promise: Promise<unknown>) => void 
  before: (promise: Promise<unknown>) => void 
  after: (promise: Promise<unknown>) => void 
  resolve: (promise: Promise<unknown>) => void 
}

const enabledCallbacks = new Set<HookCallbacks>();

Deno.core.setPromiseHooks(
  (promise: Promise<unknown>) => {
    for (const { init } of enabledCallbacks) {
      init(promise);
    }
  },
  (promise: Promise<unknown>) => {
    for (const { before } of enabledCallbacks) {
      before(promise);
    }
  },
  (promise: Promise<unknown>) => {
    for (const { after } of enabledCallbacks) {
      after(promise);
    }
  },
  (promise: Promise<unknown>) => {
    for (const { resolve } of enabledCallbacks) {
      resolve(promise);
    }
  },
);

export class AsyncHooksContextManager extends AbstractAsyncHooksContextManager {
  private _contexts: Map<Promise<unknown>, Context> = new Map();
  private _stack: Array<Context | undefined> = [];
  private _callbacks: HookCallbacks = {
    init: (promise) => {
      const context = this._stack[this._stack.length - 1];
      if (context !== undefined) {
        this._contexts.set(promise, context);
      }
    },
    before: (promise) => { 
      const context = this._contexts.get(promise);
      if (context !== undefined) {
        this._enterContext(context);
      }
    },
    after: () => {
      this._exitContext();
    },
    resolve: (promise) => {
      this._contexts.delete(promise);
    }
  }

  active(): Context {
    return this._stack[this._stack.length - 1] ?? ROOT_CONTEXT;
  }

  with<A extends unknown[], F extends (...args: A) => ReturnType<F>>(
    context: Context,
    fn: F,
    thisArg?: ThisParameterType<F>,
    ...args: A
  ): ReturnType<F> {
    this._enterContext(context);
    try {
      return fn.call(thisArg!, ...args);
    } finally {
      this._exitContext();
    }
  }

  enable(): this {
    enabledCallbacks.add(this._callbacks);
    return this;
  }

  disable(): this {
    enabledCallbacks.delete(this._callbacks);
    this._contexts.clear();
    this._stack = [];
    return this;
  }

  private _enterContext(context: Context) {
    this._stack.push(context);
  }

  private _exitContext() {
    this._stack.pop();
  }
}

As pretty much all async operation in Deno is implemented on top of Promises, tracking them should be enough to keep track of all async contexts. It should work with Deno.serve out of the box, but I didn't test it.

Again, it's fairly low level and the interface doesn't help. It would make sense to introduce a more friendly wrapper on the stdlib later on.

[legendecas]

@Grunet it is true that we can implement a context manager like AsyncHooksContextManager in Deno. However, APIs like setTimeout that are not able to be covered by promise hooks still need to be patched. It is viable to implement an AsyncLocalStorage for Deno in userland, but providing a holistic async context propagation API in Deno itself would make it easier for us to maintain a context manager for Deno.

It should work with Deno.serve out of the box, but I didn't test it.

Just like I mentioned that we don't have a native test infrastructure to run our existing test suites (and adding new tests aligning with our current pattern) with Deno. I'd be happy to know if there is any practice that we can adopt in the project.

[lucacasonato]

Deno supports AsyncLocalStorage from node:async_hooks out of the box. All native async functions preserve context, except setTimeout (we are working on this).

[Grunet]

I tried modifying the basic-tracer-node example in this repository and made 2 adjustments (outside of removing the Jaeger exporting for simplicity, just leaving the console exporting)

• Swapped in npm specifiers instead of the require's
• Added in a random fetch call using native async/await into the work being instrumented

Iirc the latter didn't used to work, but it seems to now (!)

Here's the example code https://github.com/Grunet/otel-js-deno-experimentation Let me know if I did something wrong with this little experiment!

[Grunet]

There's a little stumbling block with fetch autoinstrumentation I ran into. Documented this in the issue that if resolved will probably fix it

#3413 (comment)

[arendjr]

@legendecas Would it be acceptable to add Deno as a dev dependency for OpenTelemetry-js? If it is, I think Deno support could very well be added to the repository by making packages Deno-first and using dnt for retaining NPM support. It's probably something that should be done package-by-package given the size of the repo, but I'd be happy to open a PoC PR for this if you're open to it.

[pichlermarc]

@legendecas Would it be acceptable to add Deno as a dev dependency for OpenTelemetry-js? If it is, I think Deno support could very well be added to the repository by making packages Deno-first and using dnt for retaining NPM support. It's probably something that should be done package-by-package given the size of the repo, but I'd be happy to open a PoC PR for this if you're open to it.

@arendjr Hmm, I wonder if it would be better to start off with some Deno integration tests first. 🤔 That would be somewhat isolated, and we'd be able to figure out what's working and what is not, and we'll also be able to see if something breaks that already used to work with Deno (I think I tried the metrics SDK with Deno some time ago, but I don't know if it still works. Tests would help in that regard). 🤔

IIUC making packages deno-first would be a huge undertaking (most likely taking months). I think this would be a great topic to bring up at the SIG Meeting (we have one every Wednesday, see https://github.com/open-telemetry/community#implementation-sigs), where people can bring up comments, questions, and concerns.

[arendjr]

You’re right adding Deno integration tests might be a less intrusive first step. From my personal testing, I found most things work with Deno already, but the reliance on NPM creates some barriers, such as Deno Deploy not supporting them. But there are other ways to create native Deno releases without necessarily going Deno-first.

One notable exception we’ve found at work is the Prometheus exporter silently failing to start its webserver, so that might be a good starting point to create tests for.

IMO an advantage of going Deno-first is that it is relatively easy to support together while maintaining NPM compatibility because it is comes with more tooling out-of-the-box, so it could make for a more developer-friendly experience, so if you would be willing to discuss that at a SIG meeting that would be great. But you’re right it’s not something that would be implemented for all packages in the repo overnight, so it would need a bit of a migration plan. Let me know if you would like more input on that matter.

[pichlermarc]

You’re right adding Deno integration tests might be a less intrusive first step. From my personal testing, I found most things work with Deno already, but the reliance on NPM creates some barriers, such as Deno Deploy not supporting them.

According to this Blog post, it seems like support for npm specifiers for Deploy is in the works (denoland/deploy_feedback#314), which would take care of that limitaiton. I have to admit that I'm not too familiar with Deno: Would you mind elaborating on the other pain points that you've been facing with reliance on NPM?

But there are other ways to create native Deno releases without necessarily going Deno-first.

That sounds interesting. Would you happen to have some resources on that so that I can do some reading? 🙂 I've seen that it is much easier to do deno -> node than to do node -> deno, and I've had a hard time finding resources on the latter, so I've never considered doing a PoC on that. 🤔

Another issue that I've had back when I was trying things out was that I wasn't able to easily convert our existing tests to deno tests (due to the tooling we're using causing some trouble)

One notable exception we’ve found at work is the Prometheus exporter silently failing to start its webserver, so that might be a good starting point to create tests for.

I'd be really in favor of adding tests first for things like this; once we have some initial test setup, we can gradually expand the tests to cover more cases.

IMO an advantage of going Deno-first is that it is relatively easy to support together while maintaining NPM compatibility because it is comes with more tooling out-of-the-box, so it could make for a more developer-friendly experience, so if you would be willing to discuss that at a SIG meeting that would be great.

I'll put this on the agenda for today's SIG meeting. 🙂

But you’re right it’s not something that would be implemented for all packages in the repo overnight, so it would need a bit of a migration plan. Let me know if you would like more input on that matter.

I think we might not have the capacity to work on this at the moment as #4083 (SDK 2.0) will be the next big chunk of work we'll be focusing on and I think adding deno support simultaneously would be a large chunk of work that (I think) would increase the scope beyond what we'd be able to handle. However, as we're planning to go to 2.0, we may be able to make some breaking changes that will make it easier for us to support Deno in the future. So if you have some ideas on breaking changes that would be needed to make our future lives easier, the next few weeks would be the perfect time to bring those up. 🙂

[arendjr]

I'll put this on the agenda for today's SIG meeting. 🙂

That's great! Thanks!

So if you have some ideas on breaking changes that would be needed to make our future lives easier, the next few weeks would be the perfect time to bring those up.

I can think of one big one: Rewrite all your internal imports/exports referencing local files to use .ts extensions instead of basenames only. For example:

export * from './common/attributes'; // Current; BAD
export * from './common/attributes.ts'; // GOOD

I see you're also upgrading TypeScript for the 2.0 release, and newer versions have a allowImportingTsExtensions option that you can enable, so you shouldn't have to change anything else with regards to your current type-checking setup.

But there's a catch: The TypeScript compiler insists that you also enable either the noEmit or the emitDeclarationOnly option if you enable allowImportingTsExtensions. That means you can no longer use tsc in combination with that configuration to compile your Node packages. What I would suggest instead is to use either Rollup (more flexible) or tsup (easier setup) to compile your Node packages instead. There's the added benefit that compilation will be much faster (especially if you use SWC in combination with Rollup), although you will need a separate CI step for type-checking, because these tools don't do that.

Now, the reason all of this is actually a breaking change is that while both Rollup and tsup can generate nicely bundled index.js/index.mjs/index.d.ts files for you (which, thanks to the bundling, are also more performant to consume), you can no longer do things such as: import { getSpan } from '@opentelemetry/api/build/src/trace/context-utils', because that internal build/ directory inside your NPM package won't be there anymore. In a way I would consider that a good thing, because exposing build directories like that makes it very easy for any internal refactoring to become an unintended breaking change, but yeah, removing it altogether definitely is a breaking change :)

Now, finally, the reason why I think it would be very useful to switch to using extensions is because, as you mentioned, the importance of integration tests. I think we both agree that it would be good to run integration to test stuff in Deno, and those tests would be running inside the repository. But without those extensions, Deno has no way to directly run your sources, meaning you would always need to generate Deno-compatible packages before you could run any tests on your code. It's possible, but it likely would mean creating another build setup just for the Deno tests alone, and the DX would be far from great.

For what it's worth, I could probably find some time to work on the above if your team agrees it would be worthwhile (it would certainly help us to deliver Deno support for our own project; https://autometrics.dev)

That sounds interesting. Would you happen to have some resources on that so that I can do some reading? 🙂 I've seen that it is much easier to do deno -> node than to do node -> deno, and I've had a hard time finding resources on the latter, so I've never considered doing a PoC on that. 🤔

Yeah, I think Deno -> Node is much easier indeed, which is why I would still prefer a Deno-first approach. But especially if the extensions are fixed, that is something that could be moved towards gradually over time.

Using the current NPM-first approach still could result in specialized Deno builds though, much the same way you can create web builds from NPM packages too. It would require using a bundler, some custom config, and the occassional file with Deno-specific implementations (similar to how you already use platform/ folders with diverging implementations here and there), but it could be done. Import maps can be used for mapping the imports of NPM packages to local repository sources, and maybe for publication you would need some custom scripting to rewrite them to published URLs on https://deno.land (or a similar site), but it can be done :)

I'd be really in favor of adding tests first for things like this; once we have some initial test setup, we can gradually expand the tests to cover more cases.

Agreed that would be a good first step. Please let me know if others are open to the idea of using the .ts extensions, since it would make creating a test setup much easier.

According to this Blog post, it seems like support for npm specifiers for Deploy is in the works (denoland/deploy_feedback#314), which would take care of that limitaiton.

Ah, great to hear!

Would you mind elaborating on the other pain points that you've been facing with reliance on NPM?

Support for Deno Deploy was the main technical blocker. Beyond that I would just say that, as a Deno user, being instructed to use NPM feels very much like you're being treated as a second-class citizen, and would be a reason to look if there are other libraries that might offer Deno-native support. NPM packages also cannot use other Deno-native libraries. This may not be much of a concern for OpenTelemetry-js (I don't think you have external dependencies anyway, right?), but it's one of the reasons why Deno users may expect NPM packages to integrate less well into their ecosystem.

Personally, I also find it highly annoying that NPM packages are distributed as separate .js/.d.ts files, which prohibits clicking into a library's sources from my IDE. It's one of those things were Deno just offers a more pleasant DX out-of-the-box.

[pichlermarc]

@arendjr Thank you for the detailed answer. 🙂

We've talked about adding Deno support in the meeting yesterday, and I'll try to summarize what we talked about:

Not so good news: The main concern that the SIG (myself included) had was that we don't have the capacity right now to add official support for another runtime. We'd need a significant influx of people who are willing to work on it and who are willing to maintain it in the future. Across this repo and https://github.com/open-telemetry/opentelemetry-js-contrib, the project's scope is huge, and we're spread thin right now with just Node.js and improving browser support on the roadmap.

Good(-ish) news: The consensus seemed to be that if there is something that does also benefit us in other areas (we have not explicitly talked about deep-imports, but preventing that is something that I'd consider "beneficial in other areas"). We'd also be open for things that do not require significant effort for us to change, but will make it easier to add deno support in the future. 🙂

(Side note: We've been talking about switching up tooling in previous SIG meetings, using rollup was something that we considered too, but we decided against it as the cost/benefit ratio was unfavorable at the time. I imagine if this was brought up again with concrete ideas on how it could improve other areas, I imagine the SIG may agree to such a change. Especially if there's someone volunteering to work on it)

Please let me know if others are open to the idea of using the .ts extensions, since it would make creating a test setup much easier.

Would you mind creating a new issue for this (you can just copy over the text about allowImportingTsExtensions/rollup/tsup)? I'll then assign it to the 2.0 planning Milestone. This way, we can review the proposal as part of scope planning for 2.0. I can't promise that the proposal will be accepted, but this way, it will be visible as a more concrete action item to discuss for 2.0.

[arendjr]

Thanks! I've created the requested issue here: #4106

Totallly understandable about not wanting to diverge resources on supporting Deno right now. But just to clarify, if I offer to create some PRs to implement partial/community/experimental Deno support, do you think those might be accepted or would they be rejected out of fear of the maintenance cost?

[pichlermarc]

Thanks! I've created the requested issue here: #4106

Thanks 🙂 Added it to the milestone to discuss, and we'll put the reasoning on the issue.

Totallly understandable about not wanting to diverge resources on supporting Deno right now. But just to clarify, if I offer to create some PRs to implement partial/community/experimental Deno support, do you think those might be accepted or would they be rejected out of fear of the maintenance cost?

If we accept the proposal from #4106, I'd assume PRs adding integration tests would also be accepted.

For other changes, I think it would largely depend on the type/extent of change. Changing some features to also work on Deno would most likely be fine if the change isn't too Deno-specific (i.e. if a change also makes sense for webworkers, which we already have a testing setup for, I think there will be little pushback in merging the PR). Adding specific files to support Deno might be a tougher sell.