Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SASS support #4243

Closed
bep opened this Issue Jan 9, 2018 · 22 comments

Comments

Projects
None yet
@bep
Copy link
Member

bep commented Jan 9, 2018

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

@bep bep added the Proposal label Jan 9, 2018

@RealOrangeOne

This comment has been minimized.

Copy link
Contributor

RealOrangeOne commented Jan 9, 2018

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

This comment has been minimized.

Copy link

Jos512 commented Jan 9, 2018

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

This comment has been minimized.

Copy link
Contributor

RealOrangeOne commented Jan 9, 2018

@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

This comment has been minimized.

Copy link
Contributor

rdwatters commented Jan 9, 2018

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

This comment has been minimized.

Copy link
Contributor

biodranik commented Jan 10, 2018

  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

This comment has been minimized.

Copy link

nfisher commented Jan 12, 2018

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

This comment has been minimized.

Copy link

devjack commented Jan 16, 2018

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

This comment has been minimized.

Copy link

fbnlsr commented Jan 16, 2018

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

This comment has been minimized.

Copy link
Contributor

biodranik commented Jan 16, 2018

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

This comment has been minimized.

Copy link

andi1984 commented Jan 18, 2018

@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

This comment has been minimized.

Copy link

nfisher commented Jan 23, 2018

@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

This comment has been minimized.

Copy link

comaldave commented May 15, 2018

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

This comment has been minimized.

Copy link

fbnlsr commented May 15, 2018

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

@bep bep removed the Proposal label May 24, 2018

@bep bep added this to the v0.42 milestone May 24, 2018

@bep bep modified the milestones: v0.42, v0.43 Jun 5, 2018

@xzyfer

This comment has been minimized.

Copy link

xzyfer commented Jun 15, 2018

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

@xzyfer

This comment has been minimized.

Copy link

xzyfer commented Jun 22, 2018

@bep

This comment has been minimized.

Copy link
Member Author

bep commented Jun 22, 2018

@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

This comment has been minimized.

Copy link
Member Author

bep commented Jun 28, 2018

@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

This comment has been minimized.

Copy link

xzyfer commented Jun 28, 2018

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

@drewwells

This comment has been minimized.

Copy link

drewwells commented Jun 29, 2018

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

This comment has been minimized.

Copy link

xzyfer commented Jun 29, 2018

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

This comment has been minimized.

Copy link
Member Author

bep commented Jul 6, 2018

FIxed in dea7167

@bep bep closed this Jul 6, 2018

@xzyfer

This comment has been minimized.

Copy link

xzyfer commented Jul 6, 2018

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.