This removes `LONG_CACHE` and its descendants, which was a feature that added `?maxAge` to the live preview badges in the frontend. Since they are all static that is no longer needed, as the static badges all have longer cache timeouts regardless.
The suggest code was an exception to our usual organization pattern. There was a service test, but it's not a service. The code would sometimes regress because it wasn't being tested all the time.
This makes them no longer run as service tests, which is good because they run as part of every build. Some of them are smaller-bracket tests which is good too, because it will make them easier to test, especially as this code grows.
I'd have liked to keep using frisby for the ones that make requests to the server, though I ran into some issues with sequencing of setup that I think will require upstream changes.
Just noticed this typo and that one of the essential parts of the specification
could be worded more clearly. It seems like the hardest to enforce with SaaS
companies, so I don't think the explicitness will hurt.
The static previews don't support the social badges. Adding that lets us remove support for `exampleUrl`. Close#2479.
This includes `style` and `namedLogo` in the service-definition export and updates the frontend to use it. To accomplish this, it passes `namedLogo` through `coalesceBadge`. After logo resolution is moved to `makeBadge` this duplication can be removed, as `logo` will no longer be needed in the result of `coalesceBadge`.
The route helper functions are fairly well isolated from the rest of BaseService, with a few convenient entry points. They are easier to test in isolation.
The way the code was written before, `pathToRegexp` was invoked once for every request, which seems inefficient.
`route` was validated when it was used, though it seems more helpful to validate it up front.
This breaks out `_makeFullUrl`, `_regex`, `_regexFromPath` into new helper functions `makeFullUrl`, `assertValidRoute`, `prepareRoute`, and `namedParamsForMatch`.
It adds validation to route, and updates the services without patterns to include one, in order to pass the new validation rules.
Refs #2510
I'm going to delete or change some more logos in a further PR or two, but lets start off with the (hopefully) non-controversial ones. I think in all of these cases it is fairly clear-cut that we are not losing anything by removing our icon in favour of simple-icons now that we apply a sensible colour by default.
`base.js` is pretty long and `_makeBadgeData` is one of the most complex
functions in it.
It's a pure function so it's easy to test in isolation. This moves the function into its own module and reorganizes the tests in a way that makes it evaluate what it's doing, and easier to test what is and isn't covered.
Ref https://github.com/badges/shields/pull/2796#discussion_r249251008
* feat: udpate vs marketplace download counts to handle azure devops scenario
* chore: added documentation info to download badge for AzureDevOps on VS Marketplace
* refactor: updated VS Marketplace Downloads badge to better cover Azure DevOps extensions
* feat: added separate service for ADO extension install badges
* refactor: simplifying vs marketplace statistics transform
* refactor: finished refactoring VS Marketplace services
* docs: added inline comment on VS Marketplace service base
* Tweak docs
* refactor: tweaked validation for VS Marketplace response
* chore: added todo in VS Marketplace base
* Tweak comment
* refactor: VS Marketplace base validation cleanup
* refactor: moved rating precision in VS Marketplace
The TokenProvider abstraction was refactored away during #1205 and is now obsolete. Other users of token pooling should use TokenPool and TokenPersistence directly.
This reimplements the idea @bkdotcom came up with in #1519, and took a stab at in #1525. It’s a really powerful way to add all sorts of custom badges, particularly considering [tools like RunKit endpoints and Jupyter Kernel Gateway](https://github.com/badges/shields/issues/2259#issuecomment-444186589), not to mention all the other ways cloud functions can be deployed these days.
In #2698 we decided to put legacy helper functions in `core/legacy`. I think that’s a fine idea, though if we’re going to have a bunch of badge helper functions in there, it seems like it is probably better to keep these two important but esoteric helper functions with the core code to which they are most coupled. So I added `legacy-` to the name, and put them in `core/base-service`.
