There are a couple differences that are relevant to libraries:

1. System APIs (including fetch, etc) are entirely different from Node. Probably not relevant for this library though

2a. CommonJS-style imports/exports aren't supported; you have to use proper ES imports/exports

2b. Import paths must include the file extension, which non-Deno JS/TS often doesn't do

3. You don't use a package manager to install Deno dependencies; you import the source directly from the local file system or from a remote URL. The good news is this includes GitHub URLs! But the bad news is that eg. any transitive dependencies listed in a package.json won't be found

So... it's usually easy to port a project to Deno, but few NPM projects are compatible out of the box

One workaround that can often be used for points 2 and 3 is to load the package through something like Skypack (https://www.skypack.dev/), which will theoretically turn the whole thing into an ES module. But sometimes, depending on the library, there may still be weird issues

The sooner we can ship all libraries as ES modules by default, the better!

Regarding 2b, that’s also the case in node when using es imports, so support for that probably follows from 2a in most cases.

True, but unfortunately in TypeScript the norm is to omit the file extension (I think you even have to make configuration changes to allow otherwise). Node doesn't care because it doesn't deal with the TypeScript directly at all, so most Node-targeted TypeScript ends up not having file extensions

It works fine when imported from esm.sh