Pure ems bundle prevents emittery usage in libraries/frameworks about emittery HOT 2 CLOSED

I have no plans to add back CJS support.

Unfortunately as a library developer I cannot force my decisions down everyone else's throat

You definitely can and should. ESM has been here for many years now. Be aware that ESM+CJS has downsides too: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c?permalink_comment_id=3850849#gistcomment-3850849

that is especially true due to the still suboptimal esm experience with Typescript

ESM works fine with TypeScript if you use the correct tsconfig: https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c#how-can-i-make-my-typescript-project-output-esm

from emittery.

Be aware that ESM+CJS has downsides too

Unless I use a wrapper (which wouldn't work on deno so that would be pointless) there is little I can do about that, especially since the whole graphql ecosystem bundles dual packages and thus using instanceof is already a big hazard (let's not talk about yarn link which creates a similar issue).

By the way the dual package hazard also exists for esm-only packages that get imported in commonjs projects via async imports, yet it is being advertized as the solution to import pure esm modules into commonjs projects.

You definitely can and should

If that would be the solution to this mess I would be glad to do so, but the only goal that it will accomplish would be to flee my users to some ancient alternative without accomplishing any global transition to pure esm.

ESM works fine with TypeScript if you use the correct tsconfig

Fine, but annoying nonetheless: importing commonjs modules with default exports is a mess and the js extension in the import is counterintuitive as well.

from emittery.