This pull request closes#2551: making sure that the keywords don't already appear in the example's title.
I also added validation that checks that they are at least two characters long, as this is enforced by the homepage when type your search.
As described in #2340, this provides a way to replace an old alias with a redirect. This makes it easier to migrate our URLs over time without making our matching patterns more complicated.
The 301 redirect is sent back to the requester. If a user pastes the aliased URL into the address bar, it'll be replaced in the browser with the new URL, which gently encourages them to migrate.
Close#2340
While Next.js can handle static sites, we've had a few issues with it, notably a performance hit at runtime and some bugginess around routing and SSR. Gatsby being fully intended for high-performance static sites makes it a great technical fit for the Shields frontend. The `createPages()` API should be a really nice way to add a page for each service family, for example.
This migrates the frontend from Next.js to Gatsby. Gatsby is a powerful tool, which has a bit of downside as there's a lot to dig through. Overall I found configuration easier than Next.js. There are a lot of plugins and for the most part they worked out of the box. The documentation is good.
Links are cleaner now: there is no #. This will break old links though perhaps we could add some redirection to help with that. The only one I’m really concerned about `/#/endpoint`. I’m not sure if folks are deep-linking to the category pages.
There are a lot of enhancements we could add, in order to speed up the site even more. In particular we could think about inlining the SVGs rather than making separate requests for each one.
While Gatsby recommends GraphQL, it's not required. To keep things simple and reduce the learning curve, I did not use it here.
Close#1943Fix#2837Fix#2616
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.
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
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`.
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.
This test is being weirdly flaky in #2809. The problem seems to be in the test helper code, so I rewrote this using Joi.
I imagine the change has to do with a change to the test ordering. It's a bit puzzling.
However, the new test seems fine (and the endpoint is rarely used; not critical to begin with).
It’s happened twice that `[*]` has ended up in a PR title and the full test run has happened inadvertently. Once was me and once was a new contributor.
This raises the bar on doing it accidentally.
