For some days now my Netlify builds suddenly break when creating a stylesheet from some SCSS. The error is as evading as possible and I have no memory of changing anything in the process.
Hugo version: 0.79.0 via netlify.toml
The error that comes up (with no previous or following warning or additional notices) is:
7:46:05 PM: Error: Error building site: POSTCSS: failed to transform "style.css" (text/css): resource "scss/theme.scss_7be65e57abd2a821d9a0a498759275a5" not found in file cache
In my understanding the fact that PostCSS does not find theme.scss-cachekey points to resources.ToCSS $options being the culprit. I would however expect some more verbosity before the error that says something like “could not find file to import” or something else wrong in the SCSS process.
Not happening. I am very lost Where should I apply the crowbar?
By the way, locally it works, no error, no notice.
@bep no, it’s the latest. I am paranoid about that these days, hehe
@pointyfar I remember “simplifying” the netlify.toml… and yeah, there was a NODE_ENV in there. And that is indeed the solution.
So for posterities sake: Setting NODE_ENV to production resulted in most of my npm packages not being available because they were set as devDependencies (my conspiracy theory)… sometimes it’s so easy. And sometimes it’s better to not just add all the available config parameters
But i think you have no control on what’s inside your ground Netlify image.
All my sites have the same setup/conf but the oldest site is not exactly the same than the latter ones. Hence the explicit versions.
Yep. Check my netlify.toml above. I started to be very explicit with versions so I can be 100% sure what is going on. I think the recent major postcss release was what made me do this because somehow the local/global/netlify node version got mixed up.
I have an eye on releases of the netlify images on Github (https://github.com/netlify/build-image), but most of the explanations are gobbelydook to me. They have a list of used versions though:
To go even deeper on this, here is my “philosophy” on npm packages (not sure if they make sense and I am pretty sure this might be a weird position because the first point is something nobody ever tells you to do:
I NEVER add the package-lock.json to my repositories. Git ignore it.
I NEVER add a “relative” version to my packages. So no “~1.0.0” or “^1.0.0”. It’s ALWAYS a fixed static version number like “1.0.0”
I ALWAYS configure @dependabot on Github to either daily or weekly check my packages and update version numbers. The bot will create pull requests with updates of versions.
In my philosophy:
Patch releases are ok to “blindly” (ok, I read the changelog/commits information on these pull requests to know what changed, but I trust that they won’t break because “don’t patch release if you don’t commit to adhere to semver”) merge
Minor releases need some “brain resources” to read through the changes and decide if I can merge them blindly or need to test and adapt (git pull, checkout pull request branch, check if hugo runs, be happy and merge)
Major releases have to be thoroughly tested and changes in those releases understood, then merged.
This takes maybe 10 minutes a day for all my projects.
Why not committing package-lock.json? Because back when I did that it resulted in merge conflicts in the file that ALWAYS had to have manual edits to the files. There is a lot of hashing going on in that file and that never works out if it needs to be merged.
My way works nice (for me). I had a little stumble when PostCSS had a major release because it released one day and the plugins released the day after and that one day between nothing worked. But that’s just something one has to lived through to remember it for the next time. And with weekly checks it’s not too obvious next time.
Where should I apply the crowbar?