16 March 2018
Follow @ortaThis week we shipped a new behind-the-scenes service for CocoaPods authors: cocoapods-metadata-service it handles a subset of CocoaDocs responsibilities but does not have the requirement of running on a Mac. This makes it easier for us to maintain.
It's been almost a year since we announced that CocoaDocs was going to be shut down. CocoaDocs' sunsetting was intially slowed down by the team at BuddyBuild offering to take over the project, but the migration wasn't finished before they were acquired by Apple. This means they cannot take over community services.
Instead I've started building out a simpler replacement that handles just the needs of the cocoapods.org website. Read on to find out what that looks like.
Why build this?
CocoaPods' web infrastructure needs to continue to be hardened. We have fewer contributors and a lot more people using CocoaPods. Moving more of our web services into heroku means we have less diversity in how projects are hosted get run. Hosting a Mac Mini on the internet is a lot of work, and I wouldn't wish it on anyone else.
There's a tricky thing here though. CocoaDocs would run through the full pod install process and use the files to
generate a set of useful metrics for each pod:
install_size
total_files
total_comments
total_lines_of_code
doc_percent
readme_complexity
initial_commit_date
rendered_readme_url
license_short_name
license_canonical_url
total_test_expectations
dominant_language
builds_independently
is_vendored_framework
rendered_changelog_url
rendered_summary
spm_support
Not all of these attributes are feasible when running on heroku because it has an ephemeral filesystem. For
example a repo would include example projects and code which are removed by the pod install - CocoaDocs would then use
the remaining files to generate details on. In order to work on host without a local clone of the pod, some of those
metrics need to be optional.
I built this service to focus on the most pressing problem first: READMEs, CHANGELOGs and license information. Basically:
rendered_readme_url
license_short_name
license_canonical_url
rendered_changelog_url
Some of the other attributes can be added later, for example I see no blockers on adding dominant_language,
is_vendored_framework, initial_commit_date, spm_support and readme_complexity to the service, but some
attributes are just not going to be feasible.
This service has so far focused exclusively on Open Source GitHub projects, with plans to expand to Pods that use .tar.gz and zip files coming soon.
It's the first JavaScript project (TypeScript) in the CocoaPods org, because once I worked with TypeScript I couldn't go back to Ruby for a new project. This does introduce some complexity though. So I opted to livecode the entire process of building the v1 and getting the project into production.
This means if you're interested in how to build a small NodeJS server in TypeScript, you've got a small well-built example with a YouTube playlist of over 5 hours where I have to explain all of my choices.
As we rely more on this service, we can continue to provide the rich web-experience with far less dependencies on hard to maintain infrastructure, which paves the way for CocoaPods to continue being a useful resource for a very long time.
