As a team, we have recently made the decision to move away from Deno and migrate to Node.js. This was not a decision we made lightly, but rather one that was based on several factors.

Deno's Broken Promises: Why we had to make the switch​

One of the primary reasons we decided to make the switch was because we found that Deno had become a worse version of Node.js. While Deno promised to be more secure, simpler to use, and more modern than Node.js, we found that it fell short on some of their promises.

Deno started to feel like a worse version of Node.js. Initially, Deno was seen as a promising alternative to Node.js, but we found that it was ditching many of its principles. For example, Deno initially didn't support configs or package.json, but now it does. Additionally, they never wanted to support npm modules, but they have now added that support. The same applies to the fact that imports were only allowed via relative or absolute URLs.

Technical Issues with Deno: Difficulties in installation and usage​

In addition, our team members were facing difficulties installing Deno on their machines. Some of them spent hours trying to figure out why they couldn't install it, and it ended up being a major blocker for them. On the other hand, Node.JS is well-established and easy to install.

Another issue we faced was with the Deno LSP. It would use 100% of the CPU for no apparent reason, making it unusable. Additionally, the VSCode extension for Deno had some wonky problems, making it a frustrating experience to use.

One other issue we encountered with Deno was with its formatter. We found that it was quite inconsistent in its formatting, making it difficult to achieve a consistent codebase. In some cases, it would add unnecessary changes to every file, even if the code was already properly formatted. For instance, we had a recent PR where half of the changes were just from deno fmt, even though the code was already properly formatted. This inconsistency in formatting made it frustrating to use, and we often found ourselves spending more time trying to fix the formatting than actually writing code.

Our Focus on Efficiency and Scalability: Moving forward with Node.js​

As a result of these issues, we have decided to move to Node.js. While we understand that this may come as a surprise to some of our users, we believe that this decision is in the best interest of our community.

Moving forward, our main objective with the library remains the same - to deliver the same level of efficiency and scalability that was achieved with the Deno version. However, we have decided to transition our focus towards Node.js to take advantage of its vast ecosystem and stability. Discordeno will remain a runtime-agnostic library functioning in any javascript runtime including Deno.

Our commitment to providing a reliable library for our users​

We understand that this decision may not be popular with everyone, but we believe that it is the right decision for the future of our project. We are confident that the library will continue to provide the same level of quality and reliability that our users have come to expect from us.

This is the changelog for Discordeno.

Description​

This version began with the simple intention of trying to solve the headache of Deno installation. For a long time now, I have been unable to code on discordeno because Deno would not upgrade on my system. This meant I was stuck using Deno 1.20 while the CI would be using the latest Deno version. When I would push code, it would break as the deno format and linters and checkers would be all different. As new features were added to Deno, I was unable to use them and it made it difficult. However, because of Github Codespaces I was able to code on it for a while. Once Github Codespaces began introducing limits, I could no longer use Deno anywhere. This meant Discordeno went unmaintained for quite a while. I tried to fix Deno on my system for weeks but had no luck. However, I was not willing to remove Deno because I wanted to support existing users. Once Deno released npm support, I knew it was time to begin migrating the code of our library to NodeJS.

With that major rework, we began improving things we always wanted to do for a long time. For example, we wanted to make using rest easier as a standalone package. In the past, there was no rest.getSessionInfo() so you would need to do rest.runMethod("GET", "FIGURE OUT THE URL NOW"). This was painful and worse, it would return the values in snake case so you would need to transform them. Now you don't have to, it is all done for you automatically simply by doing rest.getSessionInfo(). In order to make this work, a lot of changes needed to happen across the codebase.

Bugs Fixed​

Features Added​

Misc Changes​

Tips For Migrating From Previous Version​

1. Find all instances of bot.helpers.getAvatarURL and replace with avatarUrl
2. Find and replace all bot.helpers.xxx with rest.xxx where xxx is any method on the helpers.