arsd: a grab bag of D modules where the dependency policy is the design
This is a collection of modules that I've released over the years. Most of them stand alone, or have just one or two dependencies in here, so you don't have to download this whole repo.
At a glance
- What is it?
- arsd is a collection of standalone D modules by Adam Druppe, now written in the OpenD dialect, and its defining rule is that each module should work on its own so you can copy one file into your project rather than adopt a framework.
- Who is it for?
- Adopt arsd if you are working in D or OpenD and need one specific piece, such as an image format reader, a zip or docx parser or a socket library, and you would rather drop in a single file than take on a package manager. Do not adopt it if you need the whole suite with guaranteed stable interdependencies, since the README says the author reserves the right to pull core.d into any module at any time.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 4 days ago.
- What is it written in?
- Mainly D, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A library you take one file from
The About section explains the shape of the project in a way that is unusual enough to be worth quoting. It is a collection of modules released over the years, the oldest originally written in 2006 before D1, for a wide variety of purposes, and most of them stand alone or have just one or two dependencies inside the repository, so you do not have to download the whole repo. That dependency policy is the design, not an accident of packaging. The author says he is always adding to it, but the policy on dependencies means you can ignore what you do not need. The audience is a D programmer who wants a working implementation of one thing, from a file format parser to a database layer, and who prefers to read and vendor a few hundred lines of source over adopting a framework with a dependency tree. The top level of the repository is a long flat list of.d files, dozens of module names, each its own file.
The OpenD fork changes who can use this
The very first section of the README is an IMPORTANT NOTE and it changes the audience. As of January 1, 2024, the repository is written in the OpenD Programming Language, which is very similar to but not the same as Walter Bright's version of the D Programming Language. The consequence is stated without hedging: there will be no further public updates with supported compatibility with WB's D language. If you depend on the code, you either contact the author to negotiate a commercial support contract, or you switch to OpenD. The README goes further and says that if things keep working from here on out, it is purely coincidental, that support requests relating to WB's D are likely to go unanswered, and that new features are not guaranteed to work. So there are now two distinct populations for this repository, OpenD users who get continued development, and Walter Bright's D users who are effectively on their own.
Modules you can pick from
The module list is the best description of the scope. From the top level entries you can see color.d, image.d, bmp.d, jpeg.d, png.d, ico.d and apng.d for image handling, plus imageresize.d and a pixmap family that the changelog mentions separately. There is html.d, dom.d, htmltotext.d, htmlwidget.d and the document formats docx.d, xlsx.d, pptx.d, rtf.d and zip.d, and the changelog confirms those were added in 12.0 along with arsd.conv. Networking is covered by http.d, http2.d, curl.d, cgi.d, eventloop.d, fibersocket.d and core.d, and there is database.d plus database_generation.d, csv.d, calendar.d, email.d, audio.d, game.d, discord.d, dbus.d, gpio.d and joystick.d for the more unusual corners. The point of listing them is that the variety is what a personal utility library looks like built up over many years, and the reason to care is that each of those files is a self contained implementation you can read.
What breaking means here, and what does not
The Breaking Changelog section is worth reading as a policy document rather than a list. It only lists changes that broke things and got a major version bump, and it did not start keeping track until 9.0. The rules are stated precisely. The author does consider changes to the build process to be a breaking change, but does not consider symbol additions, changes to undocumented members, or the occasional non-fatal deprecation to be breaking changes, since undocumented members may be changed at any time while additions and deprecations are a minor version change. The semver increases are described as very conservative, and the commitment to long-term support is stated in terms of keeping even obsolete modules compiling, and being hesitant to break backward compatibility on the ones in active use. For a consumer, that means the API you depend on is stable and the build recipe is not. The 12.0 entry shows what a break looks like in practice, where minigui's defaultEventHandler functions started taking more specific event objects and the compiler says so directly.
Error: function `void arsd.minigui.EditableTextWidget.defaultEventHandler_focusin(Event event)` does not override any function, did you mean to override `void arsd.minigui.Widget.defaultEventHandler_focusin(arsd.minigui.FocusInEvent event)`?The fix per the README is to change Event to FocusInEvent, or whatever the did you mean part names, and recompile, with no other changes necessary, unless you were constructing your own Event objects and dispatching them with loosely typed strings, in which case those need to change to the appropriate subclass.
The dependency policy relaxed in 11.0, and what it cost
The 11.0 entry is the most important one for anyone upgrading, because it is where the stand-alone promise started to bend. arsd.core was added, which caused a general build system break for users who download individual files. simpledisplay.d used to depend only on color.d and now also depends on core.d, terminal.d and http2.d were stand-alone and now depend on core.d, and minigui.d gained a dependency on a new textlayouter.d, bringing its total to minigui.d, simpledisplay.d, color.d, core.d and textlayouter.d. The author says he was relaxing the dependency policy somewhat to permit more code sharing and interoperability, that he will try to maintain some degree of stand-alone functionality, and that he reserves the right to use core.d from any module from that point forward, so you should be prepared to add it to your builds with any arsd component. The 12.0 entry says arsd.simpledisplay now uses the arsd.core event loop by default, and the recommended workflow is to clone the repo and use dmd -i so the compiler includes imported modules automatically.
Getting the code and building it
There is no package installation path in the README, and that is consistent with the whole approach. The documented way to get the code is to clone the repository, and the documented way to build is to use the D compiler's automatic module inclusion, with the author recommending that you clone the repo and use dmd -i so the compiler automatically includes imported modules, and noting that he does not require it and will call out other required cross-module dependencies in the future. For anyone who wants the standalone files instead, the same URL works as a source of individual modules to copy. The documentation list is at the arsd-official site, with the dub-enabled subpackages listed separately at code.dlang.org, and the README is careful to say that dub is no longer officially supported but may work for you anyway. There is also a dub.json at the root of the repository, and an all_for_testing.d file whose name suggests it is the aggregate entry point for building the whole set at once, plus a docs/ directory and an arsd.ddoc for generated documentation. One thing the build will not tell you nicely is a missing dependency. On Windows, arsd.core may require user32.lib and ws2_32.lib, which is added automatically in most cases, and if you hit a linker error that may be why.
Where arsd is the wrong choice
There are three limits, and the dialect one comes first. If your toolchain is Walter Bright's D, this repository is a dead end for anything but code you already depend on, and the author's own advice in that case is to negotiate a commercial support contract or move to OpenD. The second is the dependency drift. The promise that you can take one file is true for older modules and less true for newer ones, since core.d may be imported at any time by any module including dom.d, database.d and png.d, and the changelog says to assume they do. If you are vendoring files into a codebase with strict dependency hygiene, that assumption is a problem you will discover at build time rather than at design time. The alternative worth naming is a proper package ecosystem for D, where dub resolves dependencies for you and versions are declared, which costs you the read one file and adopt one thing convenience but gives you a stable dependency graph and a reproducible build. The third is that arsd is a single author's utility library, and while the long-term support commitment and conservative semver are reassuring, the bus factor is one.
Roadmap, tooling and where the project stands
The 13.0 section describes a future release, likely May 2026 or later, with pending changes that show where the author is heading. arsd.jsvar's toJson function will include null values by default to make json use cases easier, with the old behaviour recoverable by setting var.includeExplicitNullsWhenConvertingToJson to false in your thread. Two modules are being added, arsd.gr, a math library for golden ratio constants and calculations, and arsd.di, the dependency injection framework originally developed as oceandrift/di. The planned changes all point the same way: arsd.http2 will use the arsd.core event loop by default instead of requiring the -version=use_arsd_core opt in, arsd.terminal will use it sometimes, and arsd.cgi will integrate with it in some mode. The repository carries a dub.json for the dub package manager, though the README says dub is no longer officially supported and may work for you anyway, with the package list at code.dlang.org. The last push was on 2026-10-20 and the project publishes no GitHub releases, and there is a weekly blog linked from the README for change notes.
Editorial conclusion
Adopt arsd if you are working in D or OpenD and need one specific piece, such as an image format reader, a zip or docx parser or a socket library, and you would rather drop in a single file than take on a package manager. Do not adopt it if you need the whole suite with guaranteed stable interdependencies, since the README says the author reserves the right to pull core.d into any module at any time. Verify first which dialect your toolchain builds, because as of January 1, 2024 the code is OpenD and there are no further public updates compatible with Walter Bright's D.
Frequently asked questions
Can I use arsd with Walter Bright's D language?
Not with supported compatibility. The README says that as of January 1, 2024 the repository is written in OpenD, and that there will be no further public updates with supported compatibility with WB's D, so support requests relating to WB's D are likely to go unanswered.
How do I use a single module from arsd without downloading the whole repository?
That is the design. Most modules stand alone or have just one or two dependencies inside the repository, so you copy the file or files you need into your project. The author says the dependency policy means you can ignore what you do not need.
What changed in arsd 11.0 and 12.0 that could break my build?
In 11.0 the arsd.core module was added, which broke the build for users downloading individual files, and core.d became something the author reserves the right to use from any module. In 12.0, arsd.simpledisplay started using the arsd.core event loop by default, and minigui's default event handler functions started taking more specific event object types.
Which modules does arsd include?
The repository holds many standalone.d files covering image formats such as bmp, jpeg, png and ico, document formats such as docx, xlsx, pptx, rtf and zip, networking with http, http2, curl, cgi and an event loop, plus colour, database, csv, calendar, email, audio, game, gpio and joystick modules.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/adamdruppe-arsd)Was this useful?