From Open Source Contributor to Hack Day Organizer: Building SafeToDelete at Hacktoberfest

I've been contributing to open source for a while now, and I have Hacktoberfest to thank for that.

My open-source journey started during Hacktoberfest 2023. Since then, I've contributed to and maintained several open-source projects, learning a lot along the way and becoming more involved in the community.

This October, however, Hacktoberfest gave me an entirely different experience.

For the first time, Hacktoberfest introduced me to Hack Days: in-person events where developers, designers, and other tech enthusiasts come together to collaborate, build products, and solve real-world problems.

This year, I didn't just participate. I also had the opportunity to serve as the Lead Organizer of Hacktoberfest Hack Day Ikole-Ekiti x Oye-Ekiti, one of the many hack days organized across the world.

But I wasn't going to spend the entire event watching other people build.

I built something too.

Introducing SafeToDelete

I call it SafeToDelete.

You've probably inherited a codebase or contributed to one that seems to have accumulated unused files, obsolete components, legacy configurations, or dead utilities.

At some point, you've probably wondered:

Can I safely delete this file without breaking something else?

It sounds like a simple question, but answering it reliably can be surprisingly difficult.

Basic text searches (grep), linters, and conventional dead-code elimination techniques cannot always establish whether removing a file is safe.

Here are some reasons why:

• Barrels and Re-exports: These can obscure which parts of an application actually consume a module.
• Dynamic Imports and Lazy Loading: These can hide dependencies from basic static analysis.
• Path Aliases (@/...): These can make it difficult for standard directory inspection tools to resolve dependencies correctly.
• Framework Conventions and Reflection: Some frameworks load files implicitly at runtime, even when there are no obvious direct imports.
• Untested Code Paths: A successful build doesn't necessarily mean every part of an application is functioning correctly.

Deleting a file based on assumptions can introduce unexpected bugs, break functionality, or create problems that are only discovered much later.

That's the problem SafeToDelete is designed to address.

How SafeToDelete Works

SafeToDelete allows you to simulate the effect of deleting a file without actually deleting it from your working codebase.

It uses a non-destructive simulation approach to assess the potential impact of removing files.

Here's what happens:

1. Dependency Analysis: It examines the target file and identifies potential dependencies and references.
2. Isolated Git Worktree: It creates a temporary, isolated Git worktree for the simulation.
3. Simulated Deletion: The target files are removed only within that isolated environment, leaving your actual working directory untouched.
4. Build and Test Execution: It runs your project's build and test suites to identify potential breakages.
5. Risk Assessment: It generates a structured, evidence-based assessment to help you understand the potential consequences of deleting the file.

The idea is simple: know what might break before you delete it.

You can explore the project, inspect the code, and contribute on GitHub:

Explore SafeToDelete on GitHub

Other Amazing Projects Were Built Too!

SafeToDelete wasn't the only project that came out of the hackathon.

We had several amazing submissions from participants who brought different ideas, perspectives, and approaches to solving problems with software.

You can explore all the submissions here:

Explore Hacktoberfest FUOYE Hack Day Submissions

The hackathon winners were selected based on specific judging criteria. However, I'd love to hear what you think about the projects.

Take some time to explore the submissions and rank your favourites based on your own perspective. I'm particularly interested in seeing which projects stand out to you and why.

Final Thoughts

Hacktoberfest started my journey into open source in 2023. Three years later, it gave me the opportunity to help organize an event, bring people together, and build something of my own.

It's been interesting seeing how much my relationship with open source has evolved, from making contributions to existing projects to creating tools that I hope other developers will find useful.

And that's one of the things I love about open source: there's always room to learn, contribute, collaborate, and build something meaningful.

Here's to building more!