* Basic process metrics
* Enable Prometheus by an environment variable
* Code formatting
* Documentation for Prometheus metrics
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Link from README to documentation of Prometheus
* Separate module for metrics + tests
* Metrics limited by IP
* Metrics are forbidded for all requets by default
* Code refactoring
* allowedIps passed as a string to PrometheusMetrics
* Handle missing config
* METRICS_PROMETHEUS_ALLOWED_IPS added to documentation
* Log info about enabled metrics
* Unused code removed
* package-lock.json updated
* prom-client updated to 11.1.2
* Code refactoring
* Do not read IP address from X-Forwarder-For header
* Upgrade babel 6.x to babel 7.0
* Next 6.1.1 + additional babel packages needed for Babel 7.0
* Add @babel/register
* use @babel/preset-env in babel.presets to enable babel.env configuration
* define a public interface for NPM package
* move check-node-version to dependencies
* add missing file to package
* update docs
* bump version
* add gh-badges option to issue template
* abstract text measuring from users
* add a DocBlock for BadgeFactory.create()
* upgrade to Joi 14
Joi 14 throws an exception on regexes which use the `g` flag
see https://github.com/hapijs/joi/issues/1615
semver-regex uses the `g` flag
https://github.com/sindresorhus/semver-regex/blob/master/index.js
so in order to upgrade Joi, I've swapped out semver-regex
We'll use joi-extension-semver for semver validation now
* use isVPlusDottedVersionNClauses in jetbrains tests
some of these projects use version numbers like
v1.7 or
v3.0.0.141
* Precommit hook with prettier and eslint added
* Info about running prettier removed from documentation
* Info about a pre-commit hook in documentation
This is a bit of sugar that reduces the boilerplate for creating testers in what I expect will become the standard case: a service in `foo/foo-thing.service.js` with its tests in `foo/foo-thing.tester.js`.
This makes a small stylistic change, which is to name the service by its CamelCase class name rather than an invented snake-case ID. Whereas before the name was specified in `class FooThing extends Base[Json]Service` and a second time in the tester, it now only needs to be specified once.
This is a fairly simple addition of a Redis-backed TokenPersistence. When GithubConstellation is initialized, it will create a FsTokenPersistence or a RedisTokenPersistence based on configuration. Have added tests of the Redis backend as an integration test, and ensured the server starts up correctly when a `REDIS_URL` is configured.
Ref: #1848
Instead of saving tokens on a timer, save them when they change. Use EventEmitter to keep the components loosely coupled.
This is easier to reason about, much easier to test, and better supports adapting to backends which support atomic operations.
This replaces json-autosave, which was a bit difficult to read and also hard to test, with fsos, the lower-level utility it’s built on.
Ref: #1848
We use arrow functions in most places; this enforces it.
Passing arrow functions to Mocha is discouraged: https://mochajs.org/#arrow-functions
This was a mix of autofixes and hand adjustments.
When JSON responses come back, they are sometimes not in the format expected by the API. As a result we have a lot of defensive coding (expressions like `(data || {}).someProperty`) to avoid exceptions being thrown in badge processing. Often we rely on the `try` blocks that wrap so much of the badge-processing code, which catch all JavaScript exceptions and return some error result, usually **invalid**. The problem with this is that these `try` blocks catch all sorts of programmer errors too, so when we see **invalid** we don't know whether the API returned something unexpected, or we've made a mistake. We also spend a lot of time writing defensive tests around malformed responses, and creating and maintaining the defensive coding.
A better solution is to validate the API responses using declarative contracts. Here the programmer says exactly what they expect from the API. That way, if the response isn't what we expect we can just say it's an **invalid json response**. And if our code then throws an exception, well that's our mistake; when we catch that we can call it a **shields internal error**. It's also less code and less error-prone. Over time we may be confident enough in the contracts that we won't need so many tests of malformed responses. The contract doesn't need to describe the entire response, only the part that's needed. Unknown keys can simply be dropped, preventing unvalidated parts of the response from creeping into the code. Checking what's in our response before calling values on it also makes our code more secure.
I used Joi here, since we're already using it for testing. There may be another contracts library that's a better fit, though I think we could look at that later.
Those changes are in base.js.
The rest is a rewrite of the remaining NPM badges, including the extraction of an NpmBase class. Inspired by @chris48s's work in #1740, this class splits the service concerns into fetching, validation, transformation, and rendering. This is treated as a design pattern. See the PR discussion for more. There are two URL patterns, one which allows specifying a tag (used by e.g. the version badge `https://img.shields.io/npm/v/npm/next.svg`), and the other which does not accept a tag (e.g. the license badge `https://img.shields.io/npm/l/express.svg`). Subclasses like NpmLicense and NpmTypeDefinitions can specify the URL fragment, examples, the validation schema for the chunk of the package data they use, and a render function. The NpmVersion subclass uses a different endpoint, so it overrides the `handle` implementation from NpmBase.
The remaining services using BaseJsonService are shimmed, so they will keep working after the changes.
* add simple-icons
* handle undefined
* support logoColor param
* our icon > simple-icon
* dont crash ✅
* return false → undefined
* update test
* add test
* support logoColor on our logos
* cache as base64, pre-load-simple-icons, logo-helper
* add ?logoColor information
* and simple-icons reference, link to github master branch for our logos
* update simple-icons
update to 1.7.1
* Revert "and simple-icons reference, link to github master branch for our logos"
This reverts commit 5e99d5f8db.
* add link to simple-icons
* Add snapshot test
* support dash in place of space for logo name
- Present 'downloads', 'version', etc as pages
- Don't show any badges on the index page,
just links to categories.
- Tweak search so we can search all badges
from the index page, but without rendering
every badge as soon as we press a key.
