Simplify download latest release logic

[36degrees]

Within the docs we link to /prototype-admin/download-latest which looks up the latest release from GitHub and redirects to the zip download.

On the install page itself, we look up the latest release URL and then link directly to GitHub from the page.

This moves the /prototype-admin/download-latest to /docs/install so that it can live within the docs folder and unifies the two approaches so that we consistently use the /docs/download URL. This means that we are no longer blocking on a GitHub request before we can render the install page – and that we only make the request to GitHub if the user actually tries to download the kit.

Secondly, this tries to simplify the getLatestRelease function:

• Rather than trying to extract the tag name from the zipball URL, use the value of name that we get in the response data
• Use template literals to build the zip URL rather than multiple variables and concatenation
• Avoid assigning things to variables that aren't used more than once (githubUrl, options) which also reduces the amount of seeking you have to do through the code
• Remove url, zipUrl variables by assigning to releaseUrl directly and returning from every scenario

[36degrees]

Thinking about it, how often is the latest release name going to differ from what's in package.json? Are they likely to be out of sync? If not, could we read it out of the package.json file instead of making a request to GitHub?

[joelanman]

thanks, looks like a nicer approach, I'll test it out later. Just to note though that the URL is cached, so it was only ever blocking the first time it was ever called by any visit.

[NickColley]

makes sense 👍 would be good to get review applications on this repo

[NickColley]

Actually you're right, we could avoid this request entirely.

[NickColley]

Note if we keep the API request we could add the changelog notes into the download page: #404