Step 1: Favicons

The easiest way to create a complete Favicon set for a project is to use https://realfavicongenerator.net. Make sure you have the client's logo (not a text version, a picture-only version) at high-res, or as an SVG. Upload this to the site. Make sure to use the margins tools to make all the different icons look good (i.e. the ones for saved Web Apps on phones particularly), and for the Apple Touch Bar and Windows Tile ones, use the main brand colour featured in the project as the base colour.

Once these are generated and downloaded, extract the zip, and put them in the static folder of your project. There will already be a set of icons in there - these are the default Audal Logo favicons from the boilerplate and should be deleted.

Step 2: SEO Check

Navigate around the site and make sure that pages have correct title and meta description. If you're using Wordpress within the boilerplate, the SEO should all be handled automatically by gatsby-plugin-wpgraphql-seo. If you are not building a Wordpress project, then you'll need to use the SEO component in the boilerplate's components folder, and wire it up yourself.

Step 3: Hydration check

Depending on how you've built your project, you may get some 'hydration' issues with Gatsby, once the project is built. These occur because you (or one of the packages you're using) may be calling browser-specific globals (i.e. window). Most commonly you might be using Chakra-UI's useBreakpoint/useMediaQuery/useBreakpointValue functions, which DO NOT render on the build server. A quick run of gatsby build will allow you to check for these issues. Make sure you turn Javascript off in your browser when you test, so that you can see that the page still works reasonably well without Javascript enabled (to simulate a really slow JS bundle download).

Step 4: Edit siteMetadata in gatsby-config.js

You need to edit the siteMetadata in order to replace the boilerplate's existing values with ones for the client. This metadata is used as fallback metadata when React-Helmet does not provide appropriate output (or doesn't run on a particular page).

Step 5: Console check

Before shipping a project, IT IS VITAL that you check your Chrome Devtools console for errors, warnings, and logs.

If you find logs, find them in your project files and delete them.

If you find errors (you'll probably have a few missing 'key' errors for map functions), find them and fix them.

Step 6: Typescript validation

Execute npm run type-check (if the project is Typescript) to find any errors with your typings. Fix all the issues. If there's one's you really can't fix - like an external package that doesn't provide correct typings (or you just don't know how to do it) - please ask any of your supervisors to assist. With their permission, you may use @ts-ignore, @ts-expect-error, any, etc.

Step 7: ESLint validation

Execute npm run lint:fix to help you clean up any additional (mostly-non-type-related) issues in your code.

Step 8: Typescript validation (again)

Execute npm run type-check again to make sure you haven't created any new TypeScript errors when fixing mistakes identified by ESLint.

Step 9: Run complete

Execute npm run complete to run Prettier, Type Check, and ESLint in sequence. Once you have done this, a project is considered complete and ready for final code review and hand-off. Congratulations on finishing!