That is what I had to do too to get it loading using plain import. Remove UMD-wrapper and do export const fuzzysort = fuzzysortNew();
Don't think it's "crap", it's standard., but agree should be possible to get it to handle both UMD and import somehow I think.

Yes please! A build like ... at fuse.js .... to target different module patterns would be nice. Otherwise just go for esm? As this is and will be the way to go anyway on any js runtime.

i tried for days to understand how to properly distribute a js library but i can't figure it out without making a mess.

it seems like Deno works now though. they can just import a UMD module (as long as it's hosted on npm, i couldn't get it to import a local file successfully but i guess that's fine)

is an ESM build still needed? i don't like the complexity of multiple builds.

ESM support is greatly appreciated. Loading fuzzysort via UMD is sometimes unreliable, especially when it collides with the Monaco Editor loader. Because of this, I published an ESM fork of fuzzysort. However, if you are interested in providing an ESM build upstream, I would gladly contribute.

i tried for days to understand how to properly distribute a js library but i can't figure it out without making a mess.

it seems like Deno works now though. they can just import a UMD module (as long as it's hosted on npm, i couldn't get it too import a local file successfully but i guess that's fine)

is an ESM build still needed? i don't like the complexity of multiple builds.

Hello,

I woud be interested in this too.

I'm using tsup to package my packages to provide both (I'm using it with typescript project but I think it can support JS to)
Also I'm using https://publint.dev/ to validate that the package is correct, it's a great tool :)

+1 for native ESM support. We use Angular 17 and Typescript in our project and during compilation there's a waning message mentioning that CommonJS dependencies might increase bundle size and prevent optimisation: https://v17.angular.io/guide/build#configuring-commonjs-dependencies

is an ESM build still needed? i don't like the complexity of multiple builds.

I think the consensus is ESM moving forward.

i tried for days to understand how to properly distribute a js library but i can't figure it out without making a mess.

I was also in this situation when I published my first OS package where I wanted to dual emit CJS/ESM + UMD builds just for the sake of compatibility. I poured tons of hours trying to get it right (as well as the types) and I eventually settled with Rollup. It's simpler than you might think. You can just write the code in any fashion, make sure it has at least one public export, and just let the build tool do the bundling work for you. Here's my config for example in case you're interested.

Also, I do my type checks with Are the types wrong?.