uap-core: the regex data that every user agent parser shares

A repository that deliberately contains no parser

The README opens by stating what the repository is not. This repo itself does not contain a parser: only the necessary data to build one. The project is described as the core of BrowserScope's original user agent string parser, data collected over the years by Steve Souders and numerous other contributors, extracted into a separate YAML file so as to be reusable as is by implementations in any programming language. That extraction is the whole design decision, and it explains why this repository exists in the form it does. A parser is code, and code has a language, a runtime and a release cycle. The regex file has none of those. The consequence is stated plainly as well: there exists a reference implementation along with multiple production-ready implementations in various programming languages. So if you want user agent parsing, you do not install this repository, you install one of those ports, and the question worth asking is whether the port consumes this file and how current it is.

Getting the data: the uap-core npm package or a git checkout

The substance of the repository is one file, regexes.yaml, and the tree around it is deliberately minimal. The top-level entries are the .github/ directory, .gitignore, .npmignore, .npmrc, CONTRIBUTING.md, LICENSE, README.md, a docs/ directory, package.json, regexes.yaml itself, a test_resources/ directory and a tests/ directory. The npm-related files are worth a second look, because they are how you install the data without touching git. The .npmignore file excludes things from the published package, and .npmrc holds npm configuration, which together mean the YAML file is distributed over npm as well as through the repository. The npm package is named uap-core and describes itself as the regex file necessary to build language ports of BrowserScope's user agent parser. It carries the maintainers, Tobie Langel and Lindsey Simon, and declares the licence as Apache-2.0 pointing at the raw LICENSE file. So there are two ways to get the data, a git checkout for people who want to vendor it, and an npm install for people whose toolchain is JavaScript.

The tests check the data with the reference implementation

The package.json shows how the data is validated. The test script runs mocha against the ./tests directory, with the mocha configuration set to the tdd interface, a min reporter and check-leaks enabled, which is mocha's guard against global state leaking between tests. The dev dependencies explain the rest. mocha 11.6.0 is the runner, safe-regex 2.1.1 is present so the test suite can assert that the patterns in the file do not blow up the regular expression engine, yamlparser 0.0.2 handles the YAML, and uap-ref-impl is pulled directly from its git master branch as a git dependency, which is the reference implementation used to check that the regexes still behave as intended. The presence of a test_resources/ directory alongside the tests tells you the data is exercised against real user agent strings rather than only being linted. That matters because a regex file is exactly the kind of artefact that rots quietly, and a suite that runs the reference implementation over a corpus is the thing that catches a pattern that has stopped matching.

Apache-2.0 for the data, with a specific copyright holder

The licence section is short and specific. The data contained in regexes.yaml is Copyright 2009 Google Inc. and available under the Apache License, Version 2.0. That distinction between the data and the surrounding repository matters in practice. The data has a named copyright holder and an explicit licence grant, which is what lets a port in any language ship it without a per-implementation negotiation. GitHub reports the licence of the repository as a custom one it cannot classify, so the LICENSE file at the root is the authority rather than the badge. Apache-2.0 is a permissive licence with an explicit patent grant, which is a comfortable fit for a shared data file that many unrelated projects embed. This is not legal advice, and it is worth noting that the README itself refers to the licence as applying to the data, so if you are redistributing the file in a product, check the terms in the LICENSE file itself rather than assuming the repository's other files share the same grant.

Contributing a regex goes through a review guide

Changing the data is the normal way this project evolves, and the README routes contributors to a written process rather than to an issue tracker convention. The Contributing Changes to regexes.yaml section says to read the contributors' guide, CONTRIBUTING.md, and the Credits section repeats the request to contribute. The listed maintainers are Com Menthol, Lindsey Simon, Tobie Langel, Louis Barthonet and Miguel de Moura, so there is more than one person responsible for reviewing a change. The communication channels listed are a #ua-parser channel on freenode, at chat.freenode.net, and a Google Groups mailing list, both of which are older infrastructure than the rest of the project. The pattern is a classic shared-infrastructure one: many contributors, a small set of maintainers with review authority, and a document that says how to propose a change. A user agent string that a parser misclassifies is a data bug, and the fix is a regular expression, so the review question is always whether the new pattern is specific enough not to over-match.

The release tags and the package version disagree

The versioning here needs reading carefully, because the two numbers you will see say different things. The only GitHub release listed is v0.6.9, dated 2019-11-07. The package.json version field reads 0.18.0. Those are not the same numbering scheme, and the repository is not archived, with the last push on 2026-10-05, so the file itself is being worked on even though the newest tag is nearly seven years old. The practical consequence is that you should not assume a tag corresponds to the current state of the data. If you are tracking this file in your own build, pin the commit or the package version you tested rather than following a release tag. The npm package version is the one that moves with the data, and it is the number the ports that consume it will reference. The project is funded through Open Collective, as both a backer and a sponsor programme, which is the usual arrangement for an infrastructure project of this kind: many downstream users, one small maintenance burden.

Editorial conclusion

Adopt uap-core indirectly, by choosing a language port that consumes it, if you need user agent classification that matches what other tools report rather than a bespoke heuristic. Do not adopt this repository itself expecting a library, because it explicitly contains no parser, only the data needed to build one, and the only tagged release is v0.6.9 from 2019 even though the package.json version reads 0.18.0. Before you commit, read the contributors' guide for how a regex change is reviewed, check that your chosen port is still pulling the current regexes.yaml, and confirm the Apache-2.0 terms for the data match what your organisation expects from a shared dataset.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. ua-parser/uap-core on GitHub