Saving Sprockets, by Richard Schneeman


What do you do when a maintainer leaves a project with over 44 million downloads? That is what we had to consider this year when Sprockets lost the developer responsible for more than 70% of the commits. In this talk we will look at recent efforts to revive Sprockets, and make it more maintainable. We will look into how your projects can be structured to avoid burnout and survive a change of maintainers. Let's save Sprockets.


Theme: Archeology, I'll wear an Indiana Jones outfit and scream "IT BELONGS IN A MUSEUM" while talking about Sprockets. Totally serious. Other gems include "Sprockets Why'd it have to be Sprockets?"

We will start off talking about the backstory, how Sprockets and the asset pipeline came to be, and how exactly Josh left the project. We'll then go into how I came to be involved with Sprockets as it's ownership was moved over to Rails. We will then cover several technical features that were implemented including directory aware file caching and source maps. While doing this I'll talk about tips and tricks for getting familiar with a new project. Specifically writing reproducing scripts and then using application debugging techniques to figure out what is happening. I used writing documentation for other's informational purposes and as a checksum to ensure that I actually understood what the project was doing and how. After this we'll look at how we are making sprockets more approachable. I want to change the API to remove or lessen the impact of god objects. I have a strategy for involving multiple developers with ongoing changes so that if one of us leaves there will be fallbacks. I plan to expand the user level documentation to cover all major use cases. Without the capacity of developers to understand how others will use a library it is very hard to get started working on it.

Even though sprockets has a ton of method documentation and tests, it is still incredibly hard to work with. By understanding why, we can fix those problems in Sprockets and help your project avoid the same pitfalls.


Every Rails developer at this conference uses Sprockets to manage their asset pipeline. The older ones know that "sprockets is awful" but they don't know why or what to do about it. I want to change that. I am heavily involved with Sprockets. Hard to say more without identifying myself.

Edit proposal


RailsConf 2016 - Accepted [Edit]

Add submission