This is presently a head scratcher for me so I’m hoping someone can suggest something that I’ve overlooked thus far.
I have a number of projects containing Hugo+Docsy docs builds. All that I’ve tested lately (6 so far today) work fine with apparently the same setup and config and same machine, in that they build to disk with a regular hugo command, and they also will fire up the dev server on localhost just fine with a hugo -D server
…apart from one project (that happens to be the key one I need working right now)
The build process works fine, e.g.:
$ hugo
Start building sites …
hugo v0.121.2-6d5b44305eaa9d0a157946492a6f319da38de154+extended darwin/amd64 BuildDate=2024-01-05T12:21:15Z VendorInfo=brew
WARN .File.UniqueID on zero object. Wrap it in if or with: {{ with .File }}{{ .UniqueID }}{{ end }}
| EN
-------------------+--------
Pages | 14543
Paginator pages | 0
Non-page files | 7465
Static files | 75403
Processed images | 0
Aliases | 1
Sitemaps | 2
Cleaned | 0
Total in 194564 ms
However…
$ hugo -D server
Watching for changes in /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/{archetypes,content,package.json,static,themes}
Watching for config changes in /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/config/_default, /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/config/development, /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/themes/docsy/hugo.yaml
Start building sites …
hugo v0.121.2-6d5b44305eaa9d0a157946492a6f319da38de154+extended darwin/amd64 BuildDate=2024-01-05T12:21:15Z VendorInfo=brew
WARN .File.UniqueID on zero object. Wrap it in if or with: {{ with .File }}{{ .UniqueID }}{{ end }}
Change detected, rebuilding site.
2024-01-25 15:50:17.158 +0000
Built in 101806 ms
Error: error building site: TOCSS: failed to transform "scss/main.scss" (text/x-scss): "/Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/themes/docsy/assets/scss/main.scss:1:1": File to import not found or unreadable: /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/themes/docsy/node_modules/bootstrap/scss/_functions.scss.
The error is one I’ve seen before (and has various fixes I’ve looked into), but none of the solutions seem to fit (and I can’t explain why the disk build works when the in-memory one doesn’t).
We’re on the Hugo Extended version, and we have the DART transpiler in place:
hugo env
hugo v0.121.2-6d5b44305eaa9d0a157946492a6f319da38de154+extended darwin/amd64 BuildDate=2024-01-05T12:21:15Z VendorInfo=brew
GOOS="darwin"
GOARCH="amd64"
GOVERSION="go1.21.5"
github.com/sass/libsass="3.6.5"
github.com/webmproject/libwebp="v1.3.2"
github.com/sass/dart-sass/protocol="2.4.0"
github.com/sass/dart-sass/compiler="1.70.0"
github.com/sass/dart-sass/implementation="1.70.0"
The file that it is looking for is indeed at the location it says it’s looking at:
ls -la /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/themes/docsy/node_modules/bootstrap/scss/_functions.*
-rw-r--r--@ 1 carl staff 10554 Jan 25 15:32 /Users/carl/Projects/pages.oxnet/epr/catalogue/catalogue-repo/docs/themes/docsy/node_modules/bootstrap/scss/_functions.scss
The repo is an internal one, so unfortunately I can’t easily share its content to try elsewhere. I can confirm the build works on our linux CI runner (but that’s not the problem here either).
I’m trying to port this to another desktop so that I can confirm the issue repeats there (so this may be machine rather than project specific yet)…
I’ve been comparing the config against the other projects - they’re essentially identical as far as I can determine (so I’m hoping this is something really really subtle that two sets of eyes here have overlooked)
Once I’ve managed to clean up a few more pieces (the full project content is close to 0.5million pages - most of those I’ve moved out so that I can speed up the testing of this section of content - of auto-generated markdown) I’ll attempt a clean install of this into another folder…
… but if anyone can provide me with any clues as to what I’ve overlooked that can explain this oddity of a build problem I would greatly appreciate it!
Thanks!