* update ESLint related packages
* migrate to flat config format
* Fix prefer-const error
Fixes
'overrideLogoSize' is never reassigned. Use 'const' instead
* remove irrelevant eslint-disable comment
These comments came from a swizzled upstream
component but never did anything in our codebase.
ESLint 9 does not allow disable comments
for rules that are not registered.
* remove irrelevant eslint-disable comments
These were here because in the past we were applying
mocha lint rules to files which contained no tests
ESLint 9 now flags eslint-disable comments
that aren't doing anythings
* remove irrelevant eslint-disable comment
ESLint 9 now flags eslint-disable comments
that aren't doing anything
* there are no .tsx files in our code any more
* include .mjs files in linting and formatting
* update sort-class-members rule for openApi property
and update the handful of files violating it
* you missed one
* remove examples from deprecatedService()
I'm not going to replace this with openApi
We have zero examples of deprecated services that declare examples
* remove examples from redirector()
* update test
* remove compatibility code for converting examples to openApi
* remove all the code for handling examples
* remove a few bits of redundant code
* improve docs for openApi property
* last one, I promise
* fix some params incorrectly marked as optional
all of these are really required
* make '@' part of the param (not route) for scoped packages
* minor HTML tweaks to sonar help
---------
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
* update terminology
- "regular update" to "cached resource"
- "interval" to "ttl"
- move file and update imports
* set a default TTL, don't explicitly pass params if we want the default
* add tests
* update docs
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* fix: node service has bad colors #4809
* chore: minor service test rename
Co-authored-by: Caleb Cartwright <calebcartwright@users.noreply.github.com>
This will definitely save time, and ensure more uniformity.
It moves the `createServiceTester()` calls to a different place from where I'd like them, though I'm happy to have them checked by the linter.
Closes#2701
Fixes#2876 with @paulmelnikow's suggestion
Moved imports of `ServiceTester` and `createServiceTester` to a separate file so that dev dependencies are not imported by service classes.
Continue to implement #2698:
- Add `core/base-service/index.js` (but hold off on moving the things it imports)
- Add shortcuts in `services/index.js` for Base*Service, errors, and deprecatedService. This file will be streamlined later to avoid cluttering it with rarely used bits.
- Apply consistent ordering of imports and use of `module.exports` in testers.
- Remove some renaming of imports.
- Remove obsolete tests here and there.
The term “url” is overloaded in services, to refer to the Shields route and also the API URL. Calling the Shields URL a “route” is on the whole more descriptive, and makes it clearer and more obvious which one of these we’re talking about. It’s a small thing, though seems like an improvement.
We have a few functions called `buildUrl`. I’ve renamed them to `buildRoute` when they refer to routes, and left them as `buildUrl` when they refer to API URLs.
I included a minor style tweak and some formatting cleanup in `TUTORIAL.md`.
- Move the Docker Pulls badge from **Other** to **Downloads**.
- Create **Platform & Version Support** for the following:
- django version support
- python version support
- node version support
- pypi - wheel (waiting to avoid conflict with #1922)
- pipi - format (waiting to avoid conflict with #1922)
- pipi - implementation (waiting to avoid conflict with #1922)
- hhvm
- cocoapods platform
- conda
- php version badges
This implements proposals 1, 2, and 4 from #1905:
* Move gem rank from ratings to downloads; tweak title
* Move docker build from other to build
* Move bundlephobia, github file, github repo, imagelayers, and microbadger size + layers badges into new category
* Fill in a couple missing titles
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.
