Languages such as C++, C# and even Python have long been used to create 

 applications for Windows.  However, this isn't commonplace for Node applications written in JavaScript.  Here's how and why I combined existing tools to create .exe files for Node.js using 

) are executable applications for the Windows platform.  They contain a set of low-level CPU instructions thatare sequentially executed once a user opens the file by double-clicking it.

The problem with distributing JavaScript apps

I originally ran into this problem when trying to distribute 

 to customers.  I used to transpile my TypeScript code to JavaScript, then instruct customers to install Node.js and Python (remember some packages need 

 to build when installing).  I would then send a zipped folder, containing the app.

This caused many headaches.  Sometimes Node.js wouldn't be added to the user's 

Other times, install scripts would fail, they would have 2 versions of Python etc... All in all, what should be a double click to start, could take nearly an hour of setup to get going.

Compiled binaries have a few advantages over zipped bundles of JavaScript.

. No need to zip anything or make sure files are in the right folder; once downloaded, you're good to go.  Users don't care about how the app works, they just want your app to work.  This cuts out all the associated problems with a fragmented app.

.  While JavaScript can be easily read, modified and reverse-engineered by anyone with the requisite knowledge, compiled binaries are far harder to read and edit.  After being transformed to bytecode, the inner workings of your app become unobtainable knowledge to everyone bar the few modders and reverse engineers.

.  Aside from some basic requirements such as a recent-ish install of Windows (7, 10 or 11), compiled apps will work regardless of where they are given they don't rely on external dependencies.  They also have added bonus of working on any hardware, just like JavaScript running on Node.

 build sizes.  Despite the fact that Node.js is bundled into the executable, the final build size for a moderately sized app ends up around 30MB - 40MB.  Simply the 

 folder for this project is substantially larger, sitting at 200MB, and that's not even including the size of Node.js.

This was the solution I needed.  Ever since implementing the extra step to build to 

 in my build script, I haven't once thought of going back.

Alternatively, you can completely customise the appearance of the final output with a few extra fields.

, meaning we don't have to duplicate information. 

You can tweak these values how you like to personalise the output 

I also recommend adding this script to your 

For TypeScript users, you can simplify specify your 

 file as the entry and everything will be handled for you.

 is simply an abstraction, inspired by combining the power of two packages; Vercel's 

 has since been deprecated, and I've now replaced it with Node's native 

 (Single Executable Applications) and Vercel's 

, while not 100% necessary, makes our lives a lot easier.  It bundles all our project files and dependencies into a single minified bundle.  While we don't need to do this for single file projects (without dependencies), I really hope this isn't your case.  

 can also handle transpiling TypeScript, which means we don't need to employ 

 as a pre-package script.  This is key as we reduce reliance and the need for the end-user to install programs and libraries such as Node.js and the associated modules from npm.

 performs the bulk of the work, allowing us to package JavaScript with the nide binary Node.js into one package. We can use this feature to create cross-platform apps, with options to target operating systems such as Windows, macOS and Linux, depending on which platform you are on.  Using 

, we can actually create fully functional executables right away.  However, currently 

 has no support for changing the appearance or properties of the output file.  This is where 

 is a tool that allows us to directly edit certain properties of any executable file.  In this case, we're modifying the output of our 

 build, adding additional info such as an author, copyright notice, version number and an icon.  Using 

 we can make our app not only function, but also look the part too.

Creating a Windows Executable File (.exe) from a Node.js app

When it comes to Javascript, especially when working in teams, linting and consistent code formatting are non-negotiable.  For years, ESLint was the solution to this problem, providing a highly configurable way to format and lint JavaScript code and its various flavours (such as Typescript & JSX).  Given the hundreds if not thousands of settings available, many turn to established configs like 

 as a base to build their own configs on top of.  From here, you can also publish your configuration as a package on NPM with the format 

 to easily re-use it and update it across projects.

JavaScript on both the web and the server is a constantly evolving language; with new APIs, language features, frameworks and runtimes being dropped seemingly every day.  However, what this means for linting is that new rules and parsers are constantly being added and updated to support all the new additions.  When you maintain your own config, keeping up with this barrage gets tricky.

I primarily work in Typescript, for the kind of self-documenting code that the type system offers, meaning that my ESLint config needs to support Typescript too.  Thus, any base config I choose to extend must support Typescript rules and include a Typescript parser to understand the language features not included in base JavaScript.  Furthermore, a config or parser you extend, not to mention ESLint itself will also have its own dependencies, creating a rapidly growing dependency tree for what should be a small part of your application development tooling.  In my case, my config 

 would pull down around 300 packages alone.  Yes, I also think that's pretty ridiculous.  It's moments like these that make me consider dropping JavaScript for good, until I realise its still the only way to develop a web app.

After hours of wrangling dependencies and config to update my 

, I finally gave up.  The straw that broke the camel's back was the aforementioned 

 that was recently deprecated as the original author found maintaining the repository to be too time consuming and relentless.  Now I'm not blaming the author or maintainers of 

, as without their work, other config authors would have a lot more work ahead of them to get up and running.  ESLint was updated to version 9, with the major version bump signalling a lot of breaking changes to existing plugins and configs.  While breaking changes is nothing unsurmountable, what is is updating the roughly 300 package that my config directly or indirectly depends upon.  Initially I waited until slowly one-by-one, packages updated to support 

, with each day bringing the ecosystem closer to the point when I could finally update my own config.  However, after days, weeks, months and now what is nearly a year, we still weren't ready.  That's when I got this message from a long-time colleague:

Written in Rust, the JavaScript tooling world's favourite child, 

 aims to replace ESLint and Prettier with a solution that learns from the mistakes of its predecessors.  Its main claim to fame ~35 times faster formatting and linting (which I can attest to, does hold up in real, large projects), but it also includes first-class support for Typescript and JSX - a must have for my use cases.  This is huge.  No longer do we need to import new parsers and configs to create a linting system that works for what are now ubiquitous technologies.

After thoroughly reading through the docs, I decided to start putting together my own config, migrating my settings from my old ESLint config.  While Biome does have a tool for this exact scenario, I found it didn't fare so well porting over various rules from obscure plugins, so I did what any sane person would and went through every default-disabled rule on Biome and flipped certain rules on one at a time.  This endeavour took the better part of an afternoon, but in the end I had my very own config, 

.  Sitting pretty at just under 100 lines of JSON, this config defined exactly how I wanted my code to look and behave.  That's it.  No plugins, no base configs, no dependencies.

The config has exactly one peer dependency, 

 aka, Biome itself.  As JavaScript develops and so does Biome, this means I will only have to follow one project; Biome.

Since creating this config, I've switched all my active projects both work and personal to Biome and have had no qualms.  The toolchain includes popular editor integrations, enabling red squigglies with accompanying and helpful warnings and automatic refactoring suggestions.  Furthermore, I mentioned earlier that Biome is fast.  At 

, we used to lint and format our ~30,000 line codebase with ESLint which would entail waiting around for 30 seconds while the JavaScript based linter slowly worked its way through the repo.  With Biome, the story is completely different, the entire project is linted and formatted in under 1 second.

Biome Forever (or at least for the foreseeable future...)

In conclusion, Biome emerges as a compelling alternative to ESLint and Prettier, offering a one-stop-shop for linting and formatting in JavaScript projects. Biome really excels in these areas:

: Biome is built with Rust, providing significant speed improvements over JavaScript-based tools. This results in faster linting and formatting processes, enhancing developer productivity.

: Biome offers out-of-the-box support for TypeScript and JSX, eliminating the need for additional parsers or configurations.

: Biome operates with zero configuration with sensible defaults, by the customisation is there if you want it.

: With Biome, the dependency tree is entirely eliminated, removing the bloated 

With all that said, this might read like an ad, but it truly isn't, I just enjoy the tech, and for my part, I'm happy to escape dependency hell.

Linting & Formatting are Non-Negotiable: Biome over ESLint

After packaging my Gameflip command-line applications into Windows executables (as explored in a 

), end users found it significantly easier to get up and running, with setup now being a single download.  This means that they no longer needed my help to set up a clunky Node.js environment and run JavaScript directly on their computer.  Great, right? Well, yes. However, it also meant that anyone with the executable and a mouse to double-click could run the app — including those who weren't my customers.

I discovered that my application had been spreading like wildfire between Gameflip sellers with compensation returning back to me for my hard work.  If only there was a way to ensure that my customers could use the software like normal, but those with pirated copies couldn't...

DRM or Digital Rights Management is the practice of locking down software or media to limit access.  It's primary goal is to stop (or more realistically, hinder and slow) piracy.  In terms of software applications, this generally means some form of licencing system.

The solution was to set-up a licencing server.  The goal of a licencing server is to determine whether an individual or specific copy of software should be allowed to run.  In my case, I don't care where a customer runs the software from — be it their desktop, laptop or even a friends computer — as long as they are a customer.

Licence keys are simply codes that a user can enter in to validate their purchase of a certain software application.  Traditionally, these keys were algorithmically validated offline, i.e. allowing use of the program without internet, but this method has gone out of fashion.  Todays, keys are often validated against a licencing server as this process is harder to reverse engineer en masse.

While account-bound licences may seem like a sensible way to ensure that only authorised users can use software, there's a catch.  It's well known that friends and family often share a login for Netflix.  What would stop someone from doing the same with an account for your software?  The answer is that the account has to be important or valuable.  For example; its rare that you'd see someone hand over their Google account to a friend due to how much personal information is stored there.  All your emails, documents, photos and more are sensitive and important.

Luckily, we can leverage the "importance" or "value" of services like Google or Microsoft accounts to make our licence accounts valuable too.  Instead of providing a separate login for our licencing account, we can instead use OAuth to login via the aforementioned methods.  This means that in order to share the licence, a customer would also need to share the login details to their Google account... less appealing.  While it is possible for someone to create a separate Google account for the sole purpose of sharing a licence, the barrier to entry for this kind of sharing is significantly higher and as we have established, DRM isn't foolproof, it's simply a way of making piracy more inconvenient than just paying for the software in the first place.

While it's all well and fine to ensure that you aren't being stolen from using DRM, with great power comes great responsibility.  The truth is, a large amount of software featuring DRM sucks.  These piracy prevention measures often come at the cost decreased usability.  Even the act of entering a licence key in first boot is more cumbersome than just starting the software.  The games industry is notorious for creating systems that lock customers out of their accounts, data and or hurting performance.  Just take a quick search of Denuvo to see what I'm talking about.

As developers, we must keep in mind that it is our job to implement DRM in a seamless way for customers.  There are 3 factors to consider:

Does the DRM implementation adversely affect the function of the application for customers?

Will that application still work when the licensing servers are offline or sunset?

Does the DRM actually discourage or inhibit attempts at piracy?

In nearly all cases, DRM makes the user experience of software worse not only for pirates, but also legitimate users — i.e. your customers.  Your customers are paying you for a worse experience when you add DRM.  It's no wonder there is so much pushback against developers that implement DRM in attempt to bolster their bottom line.

When we add DRM, we should really think about how it will affect the user experience.  For example, with my Gameflip bot, I simply ask a user to provide a link to their Gameflip profile when purchasing their licence, and from then on, the user experience is identically to that of the software before the licencing system was implemented.  This is because in order to use the Gameflip software, the user needs to configure their Gameflip API credentials.  Now, at each startup, the software can silently check that the logged in user has purchased a licence with my licencing server.  If the check comes back positive, then the user will have no idea it even happened.

In all, this simple check takes less than a second and only requires additional action from the user once — at the time of purchase.  The DRM friction for paying customers in this case is incredibly minimal, reducing the chance that the user experience will be harmed.

It's all well and good to provide reliable licencing servers in the short term, however its a complete fantasy to believe that we as developers will maintain a project forever.  One of the major arguments against DRM is what happens when the licencing servers go down?  The system could break down for any number of reasons; the company no longer wants to pay the cost of maintenance, they can't pay it, perhaps the server moves to a different address or the API spec changes.  When building licencing into our software, we can't just code for the happy path.  We need to allow for any passive licencing failure to pass through as a success.  What do I mean by this?

Failed to resolve domain? Licencing check ✅

Couldn't parse the response? Licencing check ✅

If there is any issue validating the licence, it should instantly be treated as a valid licence.  While this policy does allow for workarounds by those smart enough to intercept the response from the licencing server, the reality is, most users will simply just buy the software because it is easier.

The last thing to think about is the most fundamental of all.  After considering the paying customer experience and adapting your solution to suit, does it prevent piracy in a meaningful way at all?  Like seriously, if its trivial to work around, what the point in implementing DRM at all?  The process takes time, testing, and inevitably some annoyed users when you mess up in production.  Just taking a few minutes to brainstorm some potential workarounds or pitfalls could save you hours of work.

DRM isn't the cure-all for piracy, it's merely an speed bump.  It's an inconvenience that should make paying for your work the easier choice, while not passing on this burden to your customers.  For the sake of all of us, developers and customers alike, I ask that when you next implement DRM into your product, take the time to think about what responsible DRM looks like.

DRM is Killing Software – Fixing It as a Developer

 allows you to automatically list hundreds of items on 

Need to create posts for GTA V, Roblox or even a redeemable code?  This program can do all of these things.

Using a CSV spreadsheet, you can create reusable listings and templates to post to Gameflip.  Within a few minutes, you can list hundreds of unique in-game items while you sit back and watch sales roll in.

Using the spreadsheet and config file, you can customize many parts of your listings, including:

The generated listings look just like manual posts, with a few search tricks under the hood to ensure your listings always show up when buyers are browsing.

The Gameflip Generic Listing Bot also includes helpful looping features, allowing you to post listings on an interval to ensure your listings are seen by customers first.

Tried and tested support in Gameflip categories such as:

 the bot and extract the zip into a folder of your choosing.  Follow the instructions in the 

 file to get started.  You will need a licence in order to run the bot so please purchase one from the link below.

Once downloaded, create a config file with the 

 and download it to the same folder as your bot.

Gameflip Generic Listing Bot

 is slow, especially when you have hundreds or even thousands of listings, generated by another tool in the Gameflip suite, such as the Gameflip Generic Listing Bot.  The Gameflip Listing Delete Bot solves this problem by providing a one-click method to take all on-sale listings down.

Many high volume sellers competing in popular Gameflip sections repost listings as often as daily to ensure their posts stay relevant in Gameflip's search tool.

Listings are rapidly removed at a rate quicker than 1 per second, meaning you'll have room to post new listings sooner.

Gameflip Listing Delete Bot

 Epic Games has removed trading from Rocket League, thus rendering this extension defunct.  This extension is no longer available for download and is no longer supported.

trades, and sit back while the trades roll in.

RLG Trade Bumper will automatically bump your trade offers on 

, allowing you to focus on trading rather than managing your trades.

 (and randomized) trade bumping delay, from 15 minutes to an hour

. Add this extension and open the "My Trades" page on Rocket League Garage to start automatically bumping.

. See when your trades were last bumped by clicking on the RLG Trade Bumper icon.

 Turn the bumper on or off whenever you like.

  Rest your eyes with an automatically toggled dark mode (depending on system preferences).

Rocket League Garage Trade Bumper is fully open source and available on 

Note: Use this extension at your own risk. ANGABLUE is in no way liable if action is taken against you for using this extension.

Rocket League Garage Trade Bumper

 is a Rocket League focussed GPT earn site, where users can earn free Rocket League items by participating in surveys, watching videos and playing games.  With over 100,000 registered users, and millions of monthly requests, 

 has been an ongoing project since 2019 where I am the lead developer, working in a team small team of 5.  The project has been a unique and useful experience in working with larger-scale production environments due to the challenges that come with a global active user base.

Cloudflare proxy, caching & DNS management

RL.Supply

 was an inventory management system allowing users to borrow, reserve and remotely view inventory of the school Makerspace.  The Makerspace was a technology and creativity lab where students could use 3D printers, electrical tools to create Arduino projects, robots and even rockets.  The space featured a large number of tools and components students could borrow, meaning keeping track of every item became difficult.  As such, the 

 project was created; a central system to keep track of who is borrowing and using any given item from the Makerspace.

Designed with mobile at the forefront, the app is available as a Progress Web App, installable on phones, tablets, desktops and also accessible via any web browser.  This provides offline support, rapid loading and navigation through the Single Page Application design.

Admins are able to manage inventory, upload images from their phones, view and edit loans, reservations and users in order to provide an accurate digital representation of the various tools present in the Makerspace.  At the same time, students can mark items as borrowed or reserve items they take from the Makerspace to show staff and other students where items may be.  Furthermore, students also receive reminders in the form of push notifications when a loan is overdue or a reserved item becomes available.

 of this project are open-sourced on GitHub.

Makerhive

 is a cross platform email templating client, commissioned by 

, a multinational cosmetic surgery clinic.  This desktop application, built for Windows, macOS and Linux using Electron allows Fue Perfect employees to quickly send consistent and polished appointment emails to customers.

After connecting to a company email address, the Fue Perfect Email App provides a template form, accompanied by a live email preview containing dynamically generated graphics depending on the surgery methods selected.  Once completed, the HTML formatted email can be sent, with a log kept for record-keeping purposes.

 on GitHub, with automated builds released on the 

Angus Bosmans

Software Engineer

Portfolio

RL.Supply

Makerhive

Fue Perfect Email App

Blog Posts

Creating a Windows Executable File (.exe) from a Node.js app

Linting & Formatting are Non-Negotiable: Biome over ESLint

DRM is Killing Software – Fixing It as a Developer

Popular Products

Gameflip Generic Listing Bot

Gameflip Listing Delete Bot

Rocket League Garage Trade Bumper

Languages & Technologies

Frontend

Languages

Frameworks

Technologies

Backend

Languages

Frameworks

Technologies

Contact

Profiles

Pages