esri.github.io: a landing page that lets GitHub do the searching

What the project actually is

The repository is described as a landing page for Esri open source projects, and the README says the same thing in one line. The homepage is esri.github.io, the primary language is JavaScript, and the licence is Apache-2.0 with a copyright notice for 2022.

The tree is small enough to read in a minute: index.html, index.js, a favicon.ico, an assets/ directory, a data/ directory, a .prettierrc, a package-lock.json and a package.json, plus the usual CODE_OF_CONDUCT.md, CONTRIBUTING.md, LICENSE and README. The topic list for the repository is css, github, html, javascript and web-development, which is a fair summary of a static site with no build step in the repository.

The last push was on 2026-07-25 and the project is not archived, but the release history has been quiet for a long time. The tagged releases are v2.0.1, v2.0.0 and v1.0, all three published on the same day in September 2017, while the package.json carries version 3.0.0. So the version numbering moved on without a tag, which tells you the project is maintained as a living website rather than released as a package.

That framing matters for anyone evaluating it. This is not a library and not a component. It is one page, with a design decision in it that is worth understanding, and the rest of this article is about that decision and what it costs.

The interesting decision: no index, just GitHub topics

The single sentence that makes this repository worth reading is in the README. Both the project categories and the search suggestions in the site are powered by GitHub topics, and the README links to the blog post that introduced topics.

Topics are GitHub's own label mechanism, so a repository declares membership in a topic and the topic pages list the repositories in it. The consequence for this landing page is that the category structure is Esri's existing GitHub organisation, not a curated list maintained in a spreadsheet or a CMS. When an Esri repository is tagged, it becomes discoverable through the page's categories without anyone touching the landing page repository.

The categories the page exposes are the same set of topics Esri uses across its GitHub presence, and the README links each one as a query against the Esri organisation: web-development, data-management, spatial-analysis, publishing-sharing and native-development. So the page's navigation is a set of links into GitHub topic search, not a set of hand-built pages.

The search suggestions work the same way. A user typing in the search box gets suggestions derived from GitHub's topic data, which means the suggestions are current because the source of truth is current, not because somebody refreshed a JSON file.

This is the design decision that shapes everything else. A landing page could have its own projects index with titles, descriptions, URLs and star counts, curated in the repository. Esri chose to derive that information from GitHub instead, which removes the curation step and the staleness that comes with it, at the cost of depending on an external API and on the accuracy of how repositories are tagged.

The projects file, and what a curated record looks like

The architecture section says that information for the case studies and featured projects can be found in data/projects.yml, and it shows what a record looks like:

- title: R Analysis
    description: Develop and share R statistical analysis with ArcGIS.
    url: //r-arcgis.github.io/
    displayLang: R
    searchLang: r
    stars: 109

Four fields carry the weight here. The title is what the reader sees, the description is the sentence under it, the url is the link, and stars is a number that was current at the time the file was written. The two language fields are the interesting pair: displayLang and searchLang, set here to R and r.

The reason for two is that a display language and a search language are not the same thing. A project written in R may be titled and described in a way that a search should match on the lower-cased identifier, while the card on the page should say R. Holding both in the record means the display stays readable and the matching stays case-insensitive, without a normalisation step at render time.

The url is written protocol-relative, as //r-arcgis.github.io/, which is the right form for a static site because the same file then works over http and https.

The stars field is the one that will go stale, and it is worth being honest about that, because it is the only number in the record that is copied rather than derived. Nothing in the data file keeps it in sync with GitHub. That is a deliberate trade: the featured and case study entries are hand-maintained records, and the star counts on them are a snapshot, while the categories and search come live from GitHub. So the site mixes two sources of truth with two different freshness characteristics, and the reader should not read the two the same way.

The stack: Calcite, Tailwind, and a static page

The development section describes the project as a simple web page driven with JavaScript, the Calcite design system from ArcGIS, and Tailwind CSS. There is no framework in that list, no bundler configuration in the tree, and no build script beyond the two placeholder npm scripts in package.json, where test echoes no test defined and start echoes load index.html in a browser.

Those two placeholder scripts are worth pausing on, because they tell you the whole deployment story. The page is index.html, the entry point in package.json is index.js, and nothing compiles them. It is a static page that you open directly or serve.

The local development loop is three steps: fork and clone the project, run npx serve in the terminal, and open the browser to the URL that is given. There is no install step and no build step, because there is nothing to install and nothing to build. The npx serve invocation is the entire toolchain for working on the page locally.

The design system choice is more significant than it looks. Calcite is Esri's own component library, so using it here means the landing page looks like an Esri product rather than like a generic open source index, and a contributor who already knows Calcite has nothing new to learn. Tailwind handles the layout and spacing. The combination means the page inherits Esri's visual language without any custom component work.

The repository also has a .prettierrc and a package-lock.json, so formatting is enforced by a standard tool and the dependency tree is pinned, even though the dependency and devDependency arrays in package.json are both empty.

Running it and contributing to it

Because there is no build, running the page locally is a single command. The README's three steps end with opening the browser to the URL given, and the URL comes from the static server that npx serve starts.

That is worth contrasting with a typical front end project, where you would install dependencies, start a dev server with hot reload, and wait for a compile. Here the loop is close to editing a file and refreshing a page, and the cost of getting a local copy running is a clone and one command.

Contributing is open in the broadest sense. The README says anyone and everyone is welcome to contribute, with a pointer to the guidelines for contributing in CONTRIBUTING.md, and the code of conduct section says all contributors and participants in this repository are expected to abide by the code of conduct, which points at Esri's organisation-level document rather than a local copy.

So the path for a contributor is: fork, clone, run npx serve, edit index.html or index.js, or add a record to data/projects.yml, and open a pull request. The project page itself is the kind of thing that gets contributions in the form of new case studies, and each one is a YAML record rather than a code change, which lowers the barrier considerably for someone who is not a front end developer.

The open question for an outside contributor is where the line between a featured project record and a plain topic-tagged repository falls, because the page supports both. The README does not spell out the criteria, and the data file is the only place that reveals the shape of the curated set.

What this repository is and is not for

It is worth being clear about the scope, because the name suggests more than the content.

It is not a component library, a build system, or a service. It is one landing page with a data file next to it, and the interesting engineering is the choice to source categories and search from GitHub topics rather than from a local index.

It is also not the place where Esri's open source work lives. Each project the page features is its own repository, with its own issues, its own releases and its own licence. The landing page is a directory, and the links it renders are GitHub search queries against the Esri organisation, so the taxonomy it displays is the taxonomy the wider GitHub ecosystem already understands rather than a classification invented for a marketing page.

There is a cost to that choice which the README does not spell out. Depending on GitHub topics means depending on a network call from the page, and the page's category and suggestion behaviour will degrade if that call is rate limited or if the topics are applied inconsistently across the organisation. The curated records in projects.yml do not have that problem, which is why both mechanisms exist.

For a team building a similar page, the takeaway is narrow and practical. If your projects are already tagged in the forge you host them on, deriving the navigation from those tags removes an ongoing maintenance task. If they are not, or if the tags are not under your control, the same page needs a maintained index instead, and the two halves of this site show what that costs: the stars field in a hand-maintained record goes stale quietly, and nothing in the file reminds you to refresh it.

Editorial conclusion

Adopt the pattern in esri.github.io if you are building a directory page for an organisation that already labels its projects with forge topics, because sourcing both the navigation and the search suggestions from those topics removes a curation step and the staleness that comes with it. Do not expect more than a static page with a data file, since there is no component, no service and no build, and do not copy the hand-maintained stars field without a way to refresh it. Before you contribute, clone the repository and run npx serve to see the page as it stands, look at data/projects.yml to understand what a curated record requires, and check whether the topics the page would query are applied consistently across the organisation, because the whole design rests on that.

Frequently asked questions

Official sources

1. Esri/esri.github.io on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases