# Shopify's open source page is a Jekyll site that counts its own repositories

> shopify.github.com is the static site behind Shopify's open source listing, built with Jekyll and Sass on GitHub Pages, where the project data comes from Jekyll's own GitHub metadata and a hand-maintained list of opt-in and non-Shopify repositories. It is MIT licensed, it still carries a 2013-era jQuery and Handlebars front end, and running it locally gives you an almost empty page by design.

**Shopify/shopify.github.com** — A collection of the open source projects by Shopify

- Repository: https://github.com/Shopify/shopify.github.com
- Website: https://shopify.github.io
- Stars: 534 · Forks: 115
- Language: CSS
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/shopify-shopify-github-com

## The page, and why a whitespace commit changes it

The repository behind Shopify's Open Source page is built with Jekyll and Sass and hosted on GitHub Pages, and the homepage is shopify.github.io.

The detail that explains the whole design is that all of the data comes from Jekyll. Any change to index.html, including whitespace-only commits, will trigger a rebuild and update all of the numbers. There is no separate data file to edit and no script to run, so the page's counters are a function of the repository's own contents.

That is an elegant idea and it has a consequence worth understanding. The list of projects and the statistics about them are not stored anywhere; they are derived at build time from the GitHub metadata that Jekyll exposes. Which means the same source, built locally, produces a different page, and that is exactly what the local build notes describe.

The primary language of the repository is recorded as CSS, which fits a site whose main job is styling a list of project cards, and the licence is MIT. The last push was on 2026-10-05 and the repository publishes no GitHub releases, so the deployment is the GitHub Pages build and there is no artefact to track.

## Two lists: repos you own and repos you do not

Adding a project to the listing is a JavaScript edit, and there are two different lists depending on who owns the code.

To include a repo in the list, you add it to optInRepos in javascripts/custom-repos.js. The repo must be owned by Shopify. To include non-Shopify repos, you use customRepos instead. And to set a defined project language or a custom avatar, you set it in the same file.

So the file is doing three jobs at once: it holds the opt-in list for owned repositories, it holds the list of external projects, and it carries the metadata that the API does not return.

The owned and unowned split is the interesting part. A repository you own is listed by opt-in, presumably because showing your own project is a decision rather than a consequence. A repository you do not own has to be listed explicitly, because the site cannot discover it. The consequence for a fork is that the opt-in list is the file you edit, and the language and avatar overrides are the escape hatch for the cases where the automatic data is wrong or missing.

The file name is the same one that the local build notes refer to for custom repo data, which is generated by GitHub's JavaScript API and therefore does show up locally.

## Running it locally, and why the page is nearly empty

The local instructions are eight steps, and the toolchain is a Ruby one with a Compass watch loop.

```text
1. Clone this branch or [download the zip](https://codeload.github.com/Shopify/shopify.github.com/zip/master) and navigate to the folder in terminal
2. Install Jekyll: `gem install jekyll`
3. Install Sass: `gem install sass`
    * Use `sass -v` to make sure it worked
4. Install Compass: `gem install compass`
5. Make sure everything is setup with `bundle install`
6. Run `bundle exec jekyll serve`
7. In another terminal window, run `compass watch`
8. Access the page at `http://localhost:4000`
```

Two processes are needed rather than one. The Jekyll server compiles the Jekyll and Sass files into static assets in the _site folder each time a file is saved, and that folder is excluded from the repository. The compass watch process updates ie.css and main.css in parallel. There is also a rake build target for manually parsing the SCSS files.

And then there is the catch, which the notes state with unusual honesty: your local build will be nearly empty. The page uses Jekyll's site.github.public_repositories object to get the repo data, and that data is only available when live. Custom repo data is generated by GitHub's JavaScript API, so it will show up locally, and the external projects are the only thing you can actually see on your own machine.

So a contributor who clones the repository and runs it locally gets the shell of the page and the hand-maintained entries, but not the automatic listing.

## Content management is delegated to each project

There is no content model to edit for the project descriptions. The content for each project comes from the GitHub Pages for that repo, either from a gh-pages branch or from the /docs directory, based on the GitHub Pages settings. The documentation prefers the /docs directory because it is less confusing for contributors.

That is a design decision with a clear rationale. A project's description, its documentation, and the entry in the listing are the same artefact in the same repository, so there is nothing to keep in sync and no second place for a contributor to forget to update. The /docs choice is preferred over a separate branch precisely because contributors already know where their docs live.

The consequence is that the listing inherits whatever the project chose to publish, and a project with no published documentation has no description in the list. The page is an index of projects rather than a curated catalogue, and that is the trade.

The repository layout matches the Jekyll convention. There is a _config.yml, a _data directory, _includes, _layouts, a css directory, images, index.html, javascripts, a script directory, a Gemfile and Gemfile.lock, and a react-native-skia directory that appears to hold a related visual asset rather than a page component.

## A dependency list that dates the front end

The dependencies section lists what is included, and it is a snapshot of a particular era of front end development.

jQuery 1.9, Modernizr, Bourbon, Handlebars.js and Isotope. All of them are described as included.

Read together, those tell you the shape of the page. Handlebars for templating project entries, Isotope for the filterable or sortable grid of projects, Modernizr for capability detection, jQuery as the runtime, and Bourbon as the Sass mixin library that sits behind the ie.css and main.css files the compass watch process updates.

Bourbon in particular is a Sass-era library, and the presence of an ie.css alongside main.css points the same way. The project is not maintained as a modern application; it is a Jekyll site whose front end has been stable for years, which is why the dependency list can be short and old at the same time.

For a fork, that is the first thing to look at. The site's structure, the data flow and the content sourcing are all still useful, but the front end stack would be the starting point for a rewrite rather than an inheritance.

## What the repository is for, and what it is not

It is worth being clear about the scope, because the name suggests something larger than it is.

This is the source of one page: Shopify's Open Source listing, the collection of open source projects by Shopify, as the repository description says. It is not a monorepo of those projects, and it is not a tool that other organisations install.

What it is good for is two things. It is a working example of a listing site whose data comes from the hosting platform's own metadata rather than from a hand-maintained index, which is a pattern worth copying. And it is a small, readable Jekyll site, so anyone can see how the pieces fit: the _data directory for content, the includes and layouts for the page structure, the javascripts directory for the custom-repos file and the API-driven data, and the css directory for the styles that compass watch maintains.

The MIT licence means you can take it. The question a forker should ask is whether the data source is available in their context, because the site depends on GitHub Pages to expose the repository metadata that fills the page.

## Conclusion

Adopt this repository if you want to run a similar listing of your own organisation's open source work, since the mechanism of using the site's own GitHub metadata plus an opt-in list is reusable. Do not adopt it as a modern front end, because the dependency list still names jQuery 1.9, Modernizr, Handlebars, Isotope and Bourbon, and a 2026 rebuild would start from a different set. Before you fork it, check two things: whether your own organisation's repository data is available to the build, because the page depends on Jekyll's public_repositories object which only exists when the site is live, and how you want non-owned projects listed, since the custom repos path is filled in by a separate JavaScript API call.

## FAQ

### How do I add a repository to the Shopify open source list?

Add it to optInRepos in javascripts/custom-repos.js, and the repo must be owned by Shopify. For non-Shopify repositories you use customRepos instead, and you set a defined project language or a custom avatar in the same file.

### How do I run the Shopify open source site locally?

Clone the repository, install Jekyll, Sass and Compass as gems, run bundle install, then start bundle exec jekyll serve and compass watch in a second terminal. The page is then at http://localhost:4000, and the Jekyll build writes its output into the _site folder.

### Why is the local build of the Shopify open source page nearly empty?

The page uses Jekyll's site.github.public_repositories object to get the repository data, and that data is only available when the site is live. Custom repo data is generated by GitHub's JavaScript API, so the external entries do show up locally while the automatic listing does not.

### Where does the description of each project come from?

From the GitHub Pages of that project's own repository, either a gh-pages branch or the /docs directory depending on the GitHub Pages settings. The documentation prefers the /docs directory because it is less confusing for contributors.

### What front end libraries does the Shopify open source page use?

The listed dependencies are jQuery 1.9, Modernizr, Bourbon, Handlebars.js and Isotope, all included in the repository. The site is built with Jekyll and Sass and hosted on GitHub Pages, and it is MIT licensed with the last push on 2026-10-05.

## Sources

- [Issues](https://github.com/Shopify/shopify.github.com/issues)
- [License: MIT](https://github.com/Shopify/shopify.github.com/blob/main/LICENSE)
- [Project website](https://shopify.github.io)
- [README](https://github.com/Shopify/shopify.github.com/blob/main/README.md)
- [Shopify/shopify.github.com on GitHub](https://github.com/Shopify/shopify.github.com)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/shopify-shopify-github-com