So this wound up being related to a minor syntax error in one of my scss files but lead me to something larger that I didn’t realize.
bud wanted an “!optional” added to an @extend I had implemented - no big deal. I didn’t see it locally because “yarn dev” was able to work through it with HMR and the single error was buried above a bunch of green successes that came afterwards (other compiled assets) and locally it still surface all my styles.
The builds run during the deployment result in the error, but it doesn’t “fail” the “build” task — it just kind of stopped it in it’s tracks, resulting in the build sort of going through while a bunch of the assets weren’t being created — but the contents of /public (largely from my last “yarn dev”) were picked up and synced to the production server still— which were at least partially the products of a dev build and resulting in the hmr stuff taking place.
My initial thoughts are admittedly largely just from how previous sage versions worked, and how running a “build” would wipe the public (or dist) directory, but also outright fail if there were blocking errors.
I sort of feel as though it would be good for a “build” to wipe the existing public directory as a first step so it doesn’t end potentially up being a mash of 2 different builds, but there could be some justification behind this working as it does.
I’m going to mark this closed because I at least understand what happened now and got it fixed, but I’ve opened a separate thread asking about whether this is all anticipated behavior and whether anyone has some good modifications to the existing build and deploy tasks to prevent scenarios like this resulting in deployed code to production environments.