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

 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.

 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 Listing Delete Bot

 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:

Gameflip Generic Listing 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

OP.Market is a high-performance digital marketplace designed for instant, secure, and data-driven trading of 

 items across Steam, Epic Games and PlayStation. Built to eliminate the delays and risks of traditional peer-to-peer trading, OP.Market functioned as a real-time exchange, pricing assets dynamically, maintaining live inventory, and executing trades within seconds. At its core, OP.Market was the spiritual successor to 

, improving on the learnings from that venture at a far larger scale.

The platform’s architecture was designed to handle the over 900,000 registered users in the single year of operation and sustain 20,000+ transactions daily while reducing downtime.

, enabling deterministic, high-speed trade execution.  The game was manually re-classed and disassembled using industry standard tools such as ReClassEx, Ghidra and Fiddler.

, delivered a responsive, localised experience in multiple languages.  Windowing and lazy loading techniques were employed to ensure the website remained performant, despite needing to display over 200,000 unique items to the user with pagination.

: Through binary decompilation, traffic interception, and protocol replication, I created a custom game client with a 

 (10 MB) than the game it was emulating, dramatically reducing infrastructure costs and enabling massive parallelism.

This last point was a key differentiatior from the prior site 

, which only used a single instance.  Distributing our inventory across 30 accounts meant that we traded with far more users in parallel (especially during times of increased volatility), but also resulted in new engineering challenges.

: primarily to enable a more robust experience and hedge against the risk of a single account being taken offline, the inventory was evenly distributed across all our accounts.  As such, pricing algorithms would constantly work to transfer assets between accounts to ensure no single account became a critical point of failure by holding too much value.

 to ensure inventory synchronisation and prevent double-selling, enqueued trades employed atomic reservatioon logic using a fine grained locking system.  In the event of failure or transaction cancellation, reservations were immediately rolled-back, freeing up assets to be traded with other users.

 incoming trades were placed in a priority queue, where users would be assigned trading accounts with the least missing items.  Missing items were instantaneously transferred between accounts to give the illusion a unified inventory, but without the associated risk.

 in a synthetic economy, maintaining buy and sell orders for every item in circulation. The system continuously adjusted its bid–ask spreads using a blend of real-time trading data, supply/demand imbalance, and game-related news signals.

To protect against overexposure, each asset was subject to automated 

. As stock levels approached overbought thresholds, bid prices were automatically reduced or suspended, reallocating liquidity toward higher-performing items, effectively mirroring 

portfolio risk management in financial trading

Due to the sheer volume of trades performed through OP.Market, this scale created unintended natural network effects, as collectors and retail traders realised that any item could be bought and sold very quickly on OP.Market.  The platform also became a venue for 

 as players used OP.Market bids/asks to inform their decisions in player-to-player trading Discord servers and forums.  This led to the creation of the official OP.Market pricing guide that algorithmically tracked market sentiment.

Beyond technical refinement, OP.Market introduced several features that accelerated user growth and retention:

 that fueled viral user acquisition, encouraging individual users and larger content creators to organically promote the service to their audiences for a mutual benefit.

, supporting multiple languages and regional currencies, enabling rapid expansion into the South American and MENA markets.

 and real-time chat integration to sustain global operations and guide users through technical difficulties.

 via Grafana for pricing performance, latency metrics, trade success rates, and system health monitoring.

These innovations translated directly to business impact, at peak, OP.Market generated 

 and established itself as the largest, most efficient Rocket League trading platform in the world.

OP.Market was ultimately shut down after 1 year of operation when 

 removed trading from the game.  This move was largely prompted by the 

 buyout of the development studio, in which the new ownership sought to transition the game's monetisation to the 

model.  At this point, the team at OP.Market had grown to 25 talented people across business, financial modelling, product development, marketing and live support.  Thankfully, this team and the tribal knowledge acquired were brought over to 

 where we continue to work in the similar, albeit uniquely challenging 

OP.Market

Rocket League Swaps (rlswaps.com) was the first fully automated trade bot and marketplace in 

.  While the concept of trading bots in game and financial economies as a whole was not new, RLSwaps brought the idea to Rocket League's player-to-play market, bridging real-world financial automation principles with the game's virtual cosmetic ecosystem.

Much alike modern day high frequency trading (HFT) firms, RLSwaps functioned as a market maker, providing liquidity to trading in Rocket League by maintaining thousands of active buy and sell positions across every cosmetic item in the game.  The bid-ask spread was dynamically adjusted using a variety of signals; real-time trading data, game news and item fundamentals.

To maintain healthy liquidity and avoid overexposure to low-value/common assets, the system incorporated inventory risk management logic.  Individual items were targged with "overstock" thresholds, preventing the bot from accumulating too much of a single illiquid asset.  As supply approached this limit, bids were gradually lowered then ultimately removed, reducing our exposure to underperforming items.

At its peak, RLSwaps managed the largest inventory by both asset count and total market value in the Rocket League virtual economy.  This scale created natural network effcts, as collectors and traders alike knew that if an item existed, it could be found or sold to RLSwaps.  Thus, the platform became a significant venue for price discovery as players quoted RLSwaps bids/asks across Discord trading groups and other similar forums.

RLSwaps

 was a Rocket League focussed "get paid to" (GPT) earn site, where users could 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, 

 was one of my largest projects at the time.

 was been an ongoing project since 2019 where I acted as the lead developer, working in a team small team of 5.  The project was 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

Angus Bosmans

Software Engineer

Portfolio

OP.Market

RLSwaps

RL.Supply

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 Listing Delete Bot

Gameflip Generic Listing Bot

Rocket League Garage Trade Bumper

Languages & Technologies

Frontend

Languages

Frameworks

Technologies

Backend

Languages

Frameworks

Technologies

Contact

Profiles

Pages