Hugo works (build to disk), but Hugo server fails - error building site: TOCSS

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!

A couple of things I’d test…

/Users/carl/Projects/pages.oxnet/epr…

Remove the dot from the directory name. I have no reason to believe that’s the culprit, but it wouldn’t hurt to try.

File to import not found or unreadable

Focusing on the “unreadable” aspect of this message, how do the owner/group/perms of this file compare to that of other projects? Do the parent dirs allow directory transversal (i.e., have x bit)?

Also, there’s a PR that’s going to land in the master branch in the next few days, and there are many changes that may (positively) affect your case.

1 Like

Remove the dot from the directory name. I have no reason to believe that’s the culprit, but it wouldn’t hurt to try.

… I’m still picking my jaw off the desk right now, but I tried this first, and it worked!

hugo -D server
Watching for changes in /Users/carl/Projects/pagesoxnet/epr/catalogue/catalogue-repo/docs/{archetypes,content,package.json,static,themes}
Watching for config changes in /Users/carl/Projects/pagesoxnet/epr/catalogue/catalogue-repo/docs/config/_default, /Users/carl/Projects/pagesoxnet/epr/catalogue/catalogue-repo/docs/config/development, /Users/carl/Projects/pagesoxnet/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 }}

                   |  EN
-------------------+--------
  Pages            | 14545
  Paginator pages  |     0
  Non-page files   |  7489
  Static files     |    30
  Processed images |     0
  Aliases          |     1
  Sitemaps         |     2
  Cleaned          |     0

Built in 30597 ms
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/catalogue/ (bind address 127.0.0.1)
Press Ctrl+C to stop

… well enough for me to see that I’ve got a problem in that one of the new pages I wanted to test has generated a 17Mb _index.md file that has become too much for practical use (several mins before page displays)

Since this has boggled the mind as to why for this one specific example this has made things work, I tested the reveral (i.e. returning the path name back to pages.oxnet)… and:

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 }}

                   |  EN
-------------------+--------
  Pages            | 14545
  Paginator pages  |     0
  Non-page files   |  7489
  Static files     |    30
  Processed images |     0
  Aliases          |     1
  Sitemaps         |     2
  Cleaned          |     0

Built in 31181 ms
Environment: "development"
Serving pages from memory
Running in Fast Render Mode. For full rebuilds on change: hugo server --disableFastRender
Web Server is available at http://localhost:1313/catalogue/ (bind address 127.0.0.1)
Press Ctrl+C to stop

…damnit. We have a suddenly unreproducible error and things are working again consistently

It makes no sense to me, but thank you @jmooring for the suggestions - somehow it has fixed my problem, even if I don’t know what that problem really was!

If you are testing with the same site, it may have worked in subsequent tests because the transpiled Sass is already in the cache.

1 Like