Option for serving un-minified assets

I second the idea that Hugo should not try to re-create web bundling toolchains. It’s a large undertaking and there are enough redundant efforts in that area. One option would support this however.

Imagine that a build tool was run (by the developer) alongside Hugo to create app.min.js and app.min.css and the HTML files loaded those. For development a simple option could rewrite the URLs to app.js and app.css which would load unminifed bundles with source maps. I think this would suffice.

There are a couple of options.

  • option to rewrite link/script tags in HTML files.
  • option to rewrite any attribute selector E.G. script[src] with a regex and a replace string
  • option to strip .min from src attributes.

I think what you want is a “development” flag or similar. We have discussed that.

Until then you can do this:

{{ if .Site.BuildDrafts }}
{{ else }}

1 Like

Thanks actually I was thinking more config for what the server does. I assume that most people use NginX or similar for actual deployment and the Hugo Server is only for development. In my experience development flags is a possibility, but it does add extra work and points of failure.

As I understand it your suggestion means that I will be writing the minified link to the generated HTML which is what I want to avoid as I deploy the generated without any preprocessing.

Each its own … but I really don’t understand. Hugo IS a STATIC site generator, so the serving part isn’t “core Hugo”. Any solution to the problem above will involve writing alternative representations of the markup. If you want something different, Wordpress and friends are good options.

Exactly it is meant to output a directory of static text. Should that not always be the same output rather than depending on the environment in which case it isn’t static. That would imply that you run Hugo on the target server, IMO a very bad idea.

My workflow is the simplest I can imagine. Run 'hugo server --buildDrafts --watch" and make changes. Commit often. The sad part is that what gets committed is a development version, so to deploy I have to do a “production” build. And the commit history is polluted by development version changes.

But I take it this is not a welcome suggestion.