* delete loads of really important stuff that we definitely need
* v basic MVP smoosh docusaurus PoC into repo
* TODO
* delete more really important stuff
* TODO
* tidyup: use run-s
* don't redirect images used in frontend to raster proxy
* fix routing
* preserve the /endpoint link
* delete the blog (for now)
I would quite like to re-add this at some point
but its not really the top priority thing right now
* content edits
* appease the lint gods
* update danger rules
* remove placeholder
* cypress tests
* dockerhub --> ghcr
* Revert "dockerhub --> ghcr"
This reverts commit ef74cbb26b.
* downgrade lockfile format
* implement defs/BASE_URL
* fix e2e build
* actually fix cypress tests
* always run cypress tests on build
* this never worked
* add command for docusaurus:clear
* delete more code we don't need any more
* update ESLint/prettier config
* delete unsused exports
* documentation updates
* delete a fairly large chunk of our dependency tree
* allow base_url as build arg to Dockerfile
* fixup dockerfile
* work out base url at runtime if not set
doing this at image build time is not the right approach
* remove gatsby monorepo from closebot
* rename HomepageFeatures to homepage-features
* expose fetchLimitBytes/userAgent in got-config module
* export a function not a factory
* send better user-agent values
- add userAgentBase setting
- send short SHA in user agent on heroku
- set a version (tag or short SHA) in Dockefile and use
it to report server version in UA for docker users
* add a comment explaining fileSize
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
Now that these s0.server.shields.io entries are set up through the main DNS on Cloudflare, we don't need the shields-server.com domain anymore. One less thing to maintain.
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 implements the configuration mechanism I described in #2621. The heavy lifting is delegated to [node-config](https://github.com/lorenwest/node-config) with a minor assist from [dotenv](https://github.com/motdotla/dotenv).
`private/secret.json` has been replaced with environment variables and/or `config/local.yml`. See `doc/server-secrets.md`.
Because `server.js` was long a monolith, there are a bunch of shims in place to facilitate unit testing. A few of the test suites share port 1111 which means if one of them fails to set up, the port won't be freed and other unrelated tests will fail. Some of the tests which trigger server setup include timeouts which were added to give setup code time to run. In one the test suites, we actually modify `process.argv`, which seems completely gross.
This implements a few changes which improve this:
1. Separate the server from the server startup script, splitting out `lib/server.js`.
2. Inject config into the server and validate the config schema.
3. Inject config into the service test runner.
4. Use `portfinder`, a popular utility for grabbing open ports during testing.
5. Switch more of the setup code from callbacks to async-await.
Overall it leaves everything acting more reliably and looking rather cleaner, if in a few places more verbose.
It also fixes the root cause of #1455, a `setTimeout` in `rate-limit`. Off and on during development of this changeset, Mocha would decide not to exit, and that turned out to be the culprit.
Fix#1455
We use arrow functions in most places; this enforces it.
Passing arrow functions to Mocha is discouraged: https://mochajs.org/#arrow-functions
This was a mix of autofixes and hand adjustments.
