Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Removing CommonJS support #117

Open
DaniFoldi opened this issue Apr 7, 2024 · 1 comment
Open

RFC: Removing CommonJS support #117

DaniFoldi opened this issue Apr 7, 2024 · 1 comment

Comments

@DaniFoldi
Copy link
Contributor

Hi people,

I and @jahands were thinking about simplifying the build toolchain of the library. Without going too much into the details of how it works, essentially the current setup creates an entirely different version for esm and cjs.

With most workers these days written using the Module Worker syntax, and with esbuild, I believe that the added package size and build complexity it not worth keeping in the lib. If you're currently using Service Worker syntax, I highly recommend following [https://developers.cloudflare.com/workers/reference/migrate-to-module-workers/#migrate-from-service-workers-to-es-modules](Cloudflare's guide) to migrate - you're losing out on features like JSRPC, Durable Objects, D1 and probably more.

The question to anyone watching the repo, or finding this issue randomly, do you actually use cjs in your workers and need continued support?

@supfilistine
Copy link

I am curious what came of this, not because I am using cjs, but I very much would like to use this with module worker formatted CF workers of my own.

When I called instrument(app.fetch, config) where app is a class that extends WorkerEntrypoint, I noticed that the SDK never ever called config to initialize the config and the Otel stuff just silently fails. It doesn't fail when I convert my Module Worker based worker to Service Worker based.

I see that all the instrumentation is accomplished through Proxies mostly, and that there are two different instrument functions, one for ExportedHandler and one for DOclass (and one for DurableObject). Why isn't there an instrumentRpc for an Rpc style class that implements WorkerEntrypoint?

I could write one myself, but setConfig is private and not exported: https://github.com/evanderkoogh/otel-cf-workers/blob/main/src/instrumentation/do.ts#L211 - so how does one provide a custom instrument function, perhaps based on the already defined instrument functions in the library?

Looked up #182 in the hopes that it will capture this use-case of Rpc based classes (Module Worker format), but don't see that there either.

What am I missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants