Symbolic links not supported

Sad to see this error.

I have all my javascript (and other) web packages managed by bower. I then set up symbolic links (in linux) from the various js files I will use within those packages to a js directory within the static folder. The idea being is if I do a bower update then hugo will use in the latest js files when it builds. I am trying to avoid putting the entire bower_components (packages) folder within the static folder because that just puts a lot of unsued files into the website itself.

Can anyone suggest an alternative workable workflow so one simple bower update command and hugo uses the latest js files?

Guess I don’t understand symbolic links well enough to understand why hugo would complain about this. I use them all the time to “fool” other programs. So is it possible that Hugo can support symbolic links in a future release? Is this really because it is an OS specific issue? I mean one would have to build for example a linux specific version?

Ask Google’s Rob Pike about why symbolic links are a challenge.

Hugo doesn’t support them because Go’s filepath.Walk doesn’t follow them:.

In the latest Hugo, an error will be printed to the console when a symbolic link is found.

1 Like

Such as it is.

For any reading who may be using bower I found this. It does what I need (i.e. puts only the required files of a package where I want them i.e. /static).

short of this there is always bash script. :-).

I came across this today… I mean the symlink error. In my case, nothing to do with Bower.

However, it actually works ( @bep )

So, in Windows, recreated the Hugoo content folder as a symlink to content_src (just as an exxperiment).

I get this ‘Symbolic links for directories not supported’, but Hugo does follow and the content is generated as it should be.

So i could do this, just have to live with the error. But am I missing something here?

filepath.Walk, the Go function doing the heavy lifting, doesn’t follow symbolic links, hence the error. But I believe that the “root folder” as a symbolic link should work, and that is what you see – and the error message is wrong. (could you create an issue at GitHub?)

So /content_src as a symbolic link seems to be fine, but /content/blog or whatever would fail. Not sure.

Thanks for the explanation, sounds like that’s what’s going on. Will create issue.


Note that this only supports symbolic links for the top-level directory of these different content paths – so /static can be a symbolic link, but not /static/js …