I just read the Deno 2 release blog, and it really got me excited about joining this ecosystem! And as a library maintainer, I’d love to know the recommended guidelines. For instance, if I want to deliver a library, it seems like I should write it in the Node.js (npm) style since Deno is compatible with Node, but not the other way around. However, this might not be great news for the Deno ecosystem and its future development. We could also suggest that maintainers publish to both npm and JSR, but that would require extra effort and might not be worth it due to Deno's compatibility with Node. I might've missed something. Any clarification would be greatly appreciated! Thanks!
#A guide for js library maintainer
sacred gulch
jade laurel
If you're writing code that targets multiple runtimes it's always best to appease to the lowest common denominator. In this case it's the API provided by Node that is supported in Deno as well.
Alternatively you could introduce some sort of adapter architecture in your code that detects whether it's running in Node or deno (check for process.versions.deno ) and swap out APIs accordingly.
sacred gulch
Thank you! I also assumed that starting with Node and then adding Deno support is a better approach. I'm a bit concerned this might impact the Deno ecosystem, as I mentioned, but I suppose people will have to go this route for now.
By the way, do you have any recommended example repositories that demonstrate how this dual or multiple runtime support is implemented? Appreciate it!
jade laurel
Yeah, in general we're not trying to fork the ecosystem, but we sure do want to push for more optimal APIs. I'm afraid I'm not aware of any example repos to link to.
wild garnet
tatami-ng (https://github.com/poolifier/tatami-ng) is using a zero cost abstraction code pattern to support several JS runtimes
peak plume
sacred gulch
Thank you so much folks! I'll look into these. ❤️