I’ve just pushed a pretty significant change to the way Hugo works internally.
As Hugo grew with contributions and features it’s become more complex. The simple sequential steps we started with have grown complex. I’ve been working on a refactor of how Hugo works with the goal of more delegation and simplifying the code.
Tonight I’ve completed the first major step towards this end. Included in todays push is:
A new handler system.
It’s still a prototype, but already does all that the previous
approach did and more. The concept here is that handlers will be defined for each file type. They are separated into page and file handlers. Page handlers are responsible for rendering into HTML and writing to the destination. File Handlers are only responsible for writing to the destination. I’ve created a couple working examples here. Markdown, Html & Css. The Markdown and Html work the same as they’ve worked for a long time. Css will minify any CSS file as it writes it to the destination. Handlers only work on files in the Content Directory. If you want a CSS file to remain unminified they place it in your Static Directory.
A new hugofs package
I’ve developed a new filesystem abstraction system called Afero. Afero provides a generic filesystem and file interfaces as well as a few implementations of this interface. OsFs simply wraps the corresponding calls from the OS package. MemMapFs is a fully safe and fast memory backed filesystem.
The beginning of the end of Targets
They were a good idea, but we can do more in a far simpler way with Afero Filesystems. Afero’s MemMapFs is far more complete and accurate then the memory target system. It provides a fully accurate mocking and in switching to using it for tests we’ve been able to identify and fix some bugs.
The targets provide translation, but this can be done seamlessly with an Afero Filesystem.
There’s still plenty more to do
Currently hugolib is way too large. The handlers shouldn’t be in hugolib. Neither should the templates and a bunch of other stuff. We need to separate more and delegate more.
I also need feedback on the handlers as well as help developing more and adding more tests around them.
Currently a lot of functionality resides in the Site & Page structs that belongs in the handlers and in filesystems. We need to rewrite this to provide more isolation and separation.
I also want to have a feature where
hugo server doesn’t write the destination files to disk, but instead saves it in memory and serves from there. It actually works right now if you just comment out the last line in the hugofs/fs.go file. Using the memory backed filesystem improves build times around 10% according to my rough benchmarks. Yup. Hugo can get even faster.
There’s a lot of things we can do with a memory backed cross platform file system.
Now that the foundation is laid. I’d love some help. A lot of the tickets in the v0.13 milestone depend on this functionality.