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
* don't use a libraries.io token for bower integration
The libraries.io docs claim you need to be authenticated
to make any API request: https://libraries.io/api#authentication
In practice we can call https://libraries.io/api/bower/jquery
just fine with no token and based on chucking a load of
requests at it and examining the `x-ratelimit-remaining`
headers you actually seem to get a better limit with no
authentication.
All of our libraries.io badges in `services/librariesio`
seem to have been running fine with no token for some time.
* change jira auth settings to jira_user, jira_pass
All the other services use servicename_user, servicename_pass
This switches JIRA to use that convention by preference
but supports _username and _password for legacy users.
* add docs for server secrets
* add danger rule for server-secrets.md
this rule prompts users to update server-secrets.md
if 'serverSecrets' is in the diff
The CSS in the project is relatively difficult to change. While it is very DRY, it relies heavily on inheritance. It's difficult to make changes in the markup modal without it also affecting styles elsewhere.
[styled-components](https://www.styled-components.com/) is one of the leading CSS-in-JS libraries. By reducing dependency on global state and CSS inheritance, styles become explicit and are easier to inspect and change. It's also convenient that styles can be embedded with the components they modify.
At runtime, the library creates CSS classes, so it's pretty efficient.
We were using a little bit of [styled-jsx](https://github.com/zeit/styled-jsx) before, which ships with Next.js, though styled-components is more widely used and I've had good experiences with it all around.
In a few cases I've duplicated styles where it feels more natural to do that: for example, `text-align: center` is duplicated in `Main` and `MarkupModal`.
Much of this is a refactor, though there are a few visual changes, particularly in the markup modal and the style examples.
* upgrade danger.js to latest version
* If PR contains tests using assert, suggest expect syntax
* if PR touches service, check service tester also touched
… so we can stop saying "you forgot to…" in code review. 😀
This idea has come up a number of times. If we can write code to detect a contributor guideline, this tool will message the contributor automatically in a pull request. This lets people fix their own problems, relieves maintainers and reviewers from nagging, and keeps anyone from having to constantly ask for more tests.
For futher reading:
- [How to use Danger well](http://danger.systems/js/usage/culture.html)
- [Examples of the kind of thing it can do](http://danger.systems/js/)
- [Dangerfile reference](http://danger.systems/js/reference.html)
