ax-vasquez/mcnuggies-blog

NextJS site & Sanity Studio code for mcnuggies.dev

mcnuggies-blog's Issues

[DEVOP] Setup CodeCov

Description

I see CodeCov used a lot in my day job, but have never actually set it up myself. I would like to understand it better, and figured this would be a good project to use to do it.

[DEVOP] Setup live demo site

Description

Setup a live demo site that reflects the latest changes and fully-demonstrates the functionality of the site.

This will be part of the "release" pipeline, whenever I find the time to put that together.

To do

1. Create ample template data in Sanity studio
   • Use the same data for template as will be used in the full demo site (so user can have the "whole setup" locally)
2. Capture more site content data in Sanity
   • Remove hard-coded site content (images/text/names/etc.)

[FEAT] Side bar

Description

Sidebar implementation to replace the current menu bar logic.

To do

1. Components
   1. SidebarContainer
   2. SidebarHeader
   3. SidebarBody
      1. SidebarBodyText
      2. SidebarBodyList
         1. SidebarBodyListItem
         2. SidebarBodyListAccordionItem
            1. SidebarAccordionChild
   4. SidebarFooter
2. Animations
   1. Sidebar slide in/out
   2. Accordion parent icon rotation on open/close
      1. Accordion child items slid down/up on open/close, respectively

General to do

• Clean up class/variable names (some of the SidebarBodyList* classes seem a bit too wordy)

[DEVOP] Implement Cypress tests

Description

At the moment, Gatsby sites can't easily be testing using Cypress' component testing. There are internal efforts at Cypress to get this working, but in the meantime, I would like to have tests of some kind in place.

To do

1. Implement Cypress tests Already have some in place; is also an ongoing effort
2. Implement Cypress CI
   1. Document CI configuration
   2. Obfuscate secrets using .env GitHub repo secrets

[DEVOP] Setup linting rules

Description

Right now, the linting solution is pretty much just drag-and-dropped from older project setups that I've used, but never really fully configured. Such is the curse of being ADHD and randomly hopping from project to project.

With that said, this one seems like one I want to stick with; after dusting it off, it worked exactly as the docs said it should. This is not a matter of me "patting myself on the back", but simply noting that I clearly gave enough of a shit to make sure the docs were good 👍 ❤️

This task should track a solid starting point for the linting rules. We should do things like:

1. Add EOF to files that don't already have them
2. Decide upon, and set a formatting standard (so no one has to worry about matching conventions - let husky do it on commit)
3. Much more (add to the list as you recall things)

To do

1. Add EOF lines to files that don't have them
2. Format files
3. Setup/refine husky
4. Prevent unused...
   1. Imports
   2. Classes
   3. Fields
   4. Allow exception for variables/classes/fields prefixed with _
5. Explicit type declarations (e.g., only allow any type when explicitly-stated - in all other cases, an undeclared type should lead to a linting error)

[FIX] Configure TailwindCSS so that unused stuff is purged

Description

Right now, TailwindCSS is a giant 💩 of code in the build and is extremely 💩 on site performance

Tailwind knows their CSS is massive, so they provide a way to purge the unused stuff, which should be most of it in the end. This site isn't very big, after all. No need to over-complicate things (though, I may need to clean up the CSS classes first 😢 )

[DEVOP] Spike - See if CircleCI would be beneficial

Description

Circle CI may be of use here, but probably in only in a limited number of cases. I need to determine if it's even worth doing since the work in this repo effectively amounts to "front end" type work; Gatsby and Sanity Studio both use their own built-in webpack servers; none of it is stuff I wrote, so it doesn't make sense to test

Most of the Gatsby site changes will be closer to vanilla front end work. The Sanity studio is a bit more custom; that will take some exploring. I'm wondering if there may be use in testing the setup between the Studio and the Gatsby site; e.g., setup an example configuration where the site is configured to listen to content changes from the source Studio ("Preview").

[DEVOP] Configure project for proper releases

Description

Right now is anarchy. There is no release process. I just slap a PR straight into main and call it a day.

While that's fine and dandy for me alone, I'd like to have more structure in place in case people want to clone this and set up their own implementation.