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
It can be helpful to have some diagnostic pages for development and quality control. I added one here for the logos, which renders all the named logos in ?style=flat and ?style=social.
This closes#2921 by switching ReSharper to the XML API used by Powershell, and refactors the powershell code back into the common nuget v2 service class. It also removes mocked tests of the color logic, replacing them with smaller-bracket tests that accomplish the same thing more concisely.
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
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.
Often when responding to bug reports it would be helpful to easily run an example failing badge URL. It takes a while to do that, because you have to copy and paste just the right part of the badge URL. This works on `img.shields.io` links as well as partial paths and should make this really easy. 💨
* Add semantic color keywords
This is based on the list I proposed at https://github.com/badges/shields/issues/1522#issuecomment-456455618. As I started documenting `default` I realized it didn't feel quite right. It's not semantic in relation to the content the way the others are, and it's also not the default left color. I changed it to `disabled` which isn't perfect, but seems better. I'm open to other suggestions.
I updated the documentation but the colors won't render correctly until this is deployed
Close#1522
* Reformat the aliases
* Pretty up the docs
* Reset whitespace changes
* Clean lint
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.
