5 ms·
I admittedly have been hesitant to jump into denoland but isn't it just a runtime for typescript? Wouldn't it work out of the box?
by nkozyra 4y ago
I admittedly have been hesitant to jump into denoland but isn't it just a runtime for typescript? Wouldn't it work out of the box?
- brundolf 4y agoThere 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/ 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!
- nicoburns 4y agoRegarding 2b, that’s also the case in node when using es imports, so support for that probably follows from 2a in most cases.
- brundolf 4y agoTrue, 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
- quackware 4y agoIt works fine when imported from esm.sh