I’ve been using bedrock/sage/trellis for a while now and I’m seeing some odd behavior lately with a sage 10 site (10.2.0).
When running a build and/or deploying, it looks like the app.css file isn’t actually getting pulled in as expected. I’m seeing the styles applied, but it looks like they’re maybe getting injected with bud/hmr?
I’m looking for a little confirmation around whether this is the expected behavior after a production build/deploy, and where exactly the handling of actually enqueuing the app.css file.
I’m also seeing these 404s repeatedly in my console after my production deploy, so I’m assuming something must just be wildly misconfigured on my end.
Sorry for the delay in responding here - holidays and all.
It’s pretty much all standard trellis and sage stuff. The build succeeds, the WP_ENV is set to “production” and the public directory has all the appropriate files with the cache-busting strings appended to the assets - it just appears that they’re all inserted via bud/hmr and no app.css file actually getting loaded.
Where would this be getting set? Prior to sage 10/bud, we would just specify something like “yarn build:production” in the actual build-before.yml file so I’m curious where I should be expecting to see this set.
Yep, tons. App.js is mostly the webpack/bud stuff with lots of react checking etc.
I’ll also see the following in my console:
Failed to load resource: the server responded with a status of 404 () from /__bud/hmr:1
TypeError: Failed to construct 'URL': Invalid URL
at Object.<anonymous> (proxy-click-interceptor.cjs:14:1)
at Generator.next (<anonymous>)
at fulfilled (proxy-click-interceptor.cjs:5:1)
(anonymous) @ proxy-click-interceptor.cjs:17
And then repeated
GET https://www.goldbergsegalla.com/__bud/hmr net::ERR_ABORTED 404
GET https://www.goldbergsegalla.com/__bud/hmr 404
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.