Hugo: Add SASS support

[bep]

This is a discussion. Thinking out loud.

With the Chroma for highlighting and the image processing added in 0.32 you have an almost complete super-fast web dev environment.

But there is one other common task that forces people to use Gulp and friends (there are of course other requirements, too, but this is the most common); to compile your CSS. With Bootstrap 4 I guess the most common one is SASS.

There is no SASS compiler in native Go, and I suspect that it will take a decade before that happens.
But there is one in C/C++ with many language wrappers:

https://github.com/wellington/go-libsass

This will, sadly, complicate the build setup. But it is doable, the question is: Is it worth it?

I'm not envisioning any "asset pipeline" for this ... Maybe we could just add SASS as a new resource type:

{{ (((.Resources.ByType "sass" ).GetByPrefix "main").ConvertTo "css").RelPermalink }} 

Or something.

Thoughts? Maybe this should wait until we "land" the plugin debate.

/cc @spf13

[RealOrangeOne]

Assuming the resources were able to sit in the static/ rather than in content/. This sounds like a great idea.

I can't see this adding any additional _runtime_ dependencies (Go should statically link the libsass library at compile time?). Build dependencies arent a massive issue, as installing libraries like libsass is often very easy. It might also be possible to only require libsass to be linked if youre calling `.ConvertTo "css" (very possible I believe).

Agreed this should be considered after plugins, as if plugins are decided as a good course of action, I think something this shouldn't be in Hugo core.

</TwoCents>

[Jos512]

Without an asset pipeline, I'm a little sceptical if SASS support is worth the work. That is, I think that most people using SASS also perform other front-end tooling tasks. So they can port one task to Hugo (SASS), but use their toolchain for the others.

(This is not me saying it's a bad idea. I just respond to the question of 'is it worth it?', which from my personal perspective I doubt. Is perhaps a poll on the Discourse forum an option to estimate the interest? I'm of course responding from my biased perspective.)

[RealOrangeOne]

@Jos512 I hadn't thought about other build lines (even though I use them myself -_- ). I think the plugin interface would solve this though? Plugins could then be created to support the different files.

(I do however now realise i'm basically describing an asset pipeline...)

[rdwatters]

I don’t think it’s worth it since SASS is most commonly one step in frontend builds along with JS.

I like the clean separation between Hugo with content (HTML, MD, JSON, images, any other text File, etc) and users picking whatever toolchain they want for presentation and behavior. Most Jekyll users I have talked to (Jekyll ships with SASS and Coffeescript support, I believe) don’t use the built-in asset pipeline, but this isn’t a data-based comment and might have to do with the Ruby implementations being slow.

I think the JS world here (Webpack CS vs Gulp, PostCSS vs SASS, etc) is really difficult to keep up with.

cc/ @budparr

[biodranik]

1. Supporting SASS is a good idea, almost everyone uses it.
2. Is go-libsass well supported? SASS is actively developing, and it would be sad to stick with an outdated implementation.
3. Plugins are the way to go. And it should be very easy in the basic implementation: just provide an easy way for authors to call any pre- and post-processing external tools they want. And disable it in themes by default for security.
4. Some of the tools should be run on a file change (e.g. SASS, autoprefixer, etc.), and it would be great to expose hugo server watch functionality to external tools, by simply binding a custom command line to modifications of specific files. This solution is not a fully flexible plugin, but it solves the most painful issues during development. Build-time functionality can be solved now by a custom shell/cmd script.

[nfisher]

I'm of two minds;

1. urban sprawl of tooling can be a little annoying to set-up in CI pipelines based on docker so 👍 to batteries included.
2. adding more features and functionality to Hugo risks bloating it from it's sharp focus on "fast" static site generation.

As a short-term goal is there a way to specify external commands that get run on each generation?

Naive approach could be addition of something like this in config.toml perhaps?

[production]
before = ["sass ...", "webpack... "]
after = ["minify ..."]

[dev]
before = ["sass ...", "webpack... "]
after = ["minify ..."]

[devjack]

Hugo is, for me, a fantastic generation tool that plays an important part in my publishing pipeline. I use it in combination with webpack/gulp/sass etc. to produce sites. My gut tells me documentation/examples/ecosystem around combined tooling is more beneficial than replicating existing community functionality in hugo.

[fbnlsr]

SASS support would be a great addition to Hugo. I agree with @devjack though, focus should be on documentation and ecosystem, as it's rather simple to set up a Webpack / Gulp tooling when working with Hugo. Especially when considering the first post stating that even if it's doable, it's something that would be hard to implement and complicate the build setup.

One thing that could be more beneficial though is a hook system to trigger commands before and after building. At the moment I'm using NPM tasks to run my build/serve/watch tasks, which look like this:

"scripts": {
    "build": "webpack && hugo",
    "serve": "webpack && hugo serve",
    "watch": "parallelshell 'hugo serve' 'webpack --watch'"
  }

A simple built-in hook system in Hugo could help users set up a more streamlined development environment and be more flexible imho. It'd also help reduce the number of dependencies needed.

[biodranik]

It would be great to reuse hugo's watch functionality and add custom hooks on file changes for more flexibility. In this case it would be very easy to call any external script/tool/sass/webpack/anything to preprocess files.

There is no any easy/cross-platform/no-filesystem-polling solution available, and golang portability can solve it.

[andi1984]

@bep I'm with @devjack opinion: static assets like images, audio, video etc. is in general fine for me when Hugo optimizes them. But I think it is not worth effort trying to build something others already do. I'm using Sass and Gulp myself. But might be that in few months it will be grunt, postcss or whatever else is out there.

I think Hugo should not care about that.

[nfisher]

@bep I think I could probably add some rudimentary SASS capabilities with PR #4278.

I would approach it by adding an additional "tag".

{{ sass OUTFILE, INFILE | safeHTML }}

~There's a few features that I think need to be added;~

• ~caching (e.g. on OUTFILE).~
• ~hooking into http handler.~
• ~serving from memory.~

I need to do those anyway for that PR but I could see it being used similarly here.

[comaldave]

I am placing my TS and SCSS files in /src/ and then process them along with webpack to create CSS and JS in /static/

@Biodranik

It would be great to reuse hugo's watch functionality and add custom hooks on file changes for more flexibility. In this case it would be very easy to call any external script/tool/sass/webpack/anything to preprocess files.

[fbnlsr]

Same here. I ended up using Webpack as well. I've got an npm script which launches webpack and hugo in parallel with the watch flag and it's working like a charm.

You can see it here: https://github.com/fbnlsr/primative.net

[xzyfer]

LibSass maintainer here 👋 happy to help out or answer any questions

[xzyfer]

As far as I know there is no rust Sass. The oy rust binding I know is using
LibSass under the covers.

On Fri., 22 Jun. 2018, 6:21 pm Josh Habdas, [e-mail]
wrote:

@xzyfer https://github.com/xzyfer I noticed Discourse is using Sass. Do
you know offhand if they're using LibSass or Rust?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gohugoio/hugo/issues/4243#issuecomment-399362887, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAjZWFwyuvbSyjVC1VfsZB_irjyLTgFlks5t_KkkgaJpZM4RXvg7
.

[bep]

@jhabdas is right; this is an opinionated choice, but it's very useful to a bunch of people (me included), and even if is opinionated it is also really the only choice we could make if we wanted to add a fast CSS preprocessor in Hugo.

I have said it before, but I will say this again: I'm willing to give away lots of flexibility and modern buzz word components in my workflow I that means that I can use hugo for all of it.

[bep]

@xzyfer are these WARNINGs familiar?

# github.com/gohugoio/hugo/vendor/github.com/wellington/go-libsass/libs
In file included from cencode.c:2:
../vendor/github.com/wellington/go-libsass/libs/../libsass-build/cencode.c:50:5: warning: declaration does not declare anything [-Wmissing-declarations]
../vendor/github.com/wellington/go-libsass/libs/../libsass-build/cencode.c:64:5: warning: declaration does not declare anything [-Wmissing-declarations]

I assume "no harm", but they are annoying to get every time I build. Know any magic flag I can set to turn these warnings off?

[xzyfer]

@bep you'll need to talk to @drewwells about the golang side of things

[drewwells]

Those are c build errors we should probably figure out why these are missing. Kind of funny that c calls this a warning.

There's a bunch of options to remove warnings here https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_the_GNU_Compiler_Collection/warning-options.html

@xzyfer do you know where these declarations exist?

[xzyfer]

I don't but I can take a look. A bunch of compiler warning were introduced in a recent major refactor I wasn't involved in. Safe to ignore these for now but we'll continue to address these as time permits.

[bep]

FIxed in dea71670c059ab4d5a42bd22503f18c087dd22d4

[xzyfer]

:tada: