You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
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?
The text was updated successfully, but these errors were encountered: