🐶 Add Husky pre-commit context-based explanations

[JFWooten4]

Over the years writing #723 from a few different computers, I ran into a lot of fun situations with the Husky precommit. I started finicking around with it when I got stuck in an airport and couldn't commit locally because of some improper config on a laptop terminal. From there, it expanded to support for local environments that ran a wildly different OS from the cloud shell that compiles the site and runs the GitHub Actions checks.

This started piecing together when I could run the Actions call remotely from the VS Code extension. I was able to isolate what went wrong with local mismatches and write out a fix script path that kept development possible despite configuration technical hiccups. I found myself temporarily importing it in cross-build branches just to allow valid commits.

I really don't see how this repo doesn't have a more fleshed out process like this. Not everyone starts off with advanced computer or terminal familiarity, and that makes it hard to work on the docs locally. My proxy for that is the number of new contributions using anything other than a patch-* name from the native edit branch function on the GitHub website.

Hopefully we'll enable a lot more of that now that it's not 20 minutes of config to get the commit box working! As for safety, the PR will still need to pass the script in Actions, so I think we're totally fine. And it preserves the Prettier echo warnings that can pop up to make clear why their PR may have an ❌

[Copilot]

Pull request overview

Updates the Husky pre-commit hook to be more environment-aware so contributors aren’t blocked from committing when local Node/Yarn tooling doesn’t match the repo’s required setup (Node >= 24), while still providing actionable output when formatting checks do run.

Changes:

• Add Node/NVM setup logic and skip behavior when Node v24 isn’t available.
• Add Yarn presence check and more descriptive output around MDX formatting checks.
• Capture yarn check:mdx output to provide tailored hints/warnings.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

On any check:mdx failure, the hook always prints a formatting-specific hint to run yarn run format:mdx. check:mdx can also fail for non-format reasons (e.g., dependencies not installed / prettier missing), in which case the hint is misleading and the follow-up command won’t help. Consider detecting the “code style issues found” case vs other failures and tailoring the guidance (e.g., suggest yarn install when scripts/binaries are missing).

Suggested change

	echo -e "${G}Hint:${CLEAN} Run ${P}yarn run format:mdx${CLEAN} to fix formatting."
	if echo "$CHECK_OUTPUT" | grep -Eq 'Code style issues found|\[warn\]|check failed'; then
	echo -e "${G}Hint:${CLEAN} Run ${P}yarn run format:mdx${CLEAN} to fix formatting."
	elif echo "$CHECK_OUTPUT" | grep -Eq 'Command "check:mdx" not found|error Command "check:mdx" not found|prettier: not found|command not found|Cannot find module|MODULE_NOT_FOUND'; then
	echo -e "${G}Hint:${CLEAN} Dependencies or required scripts may be missing. Run ${P}yarn install${CLEAN} and try again."
	else
	echo -e "${G}Hint:${CLEAN} check:mdx failed for a non-formatting reason. Review the error output above and verify your dependencies are installed."
	fi

[JFWooten4]

This could be a new issue if you're really worried about it. I cover the Node and Yarn problems before running it. This is the only functionality now, so I'd like to step it up to this before worrying about minutiae. I already cover the corner cases I've experienced on a pretty wide array of mismatched runtimes.