HUGO

Javascript not working in production or public directory

Dear all,

I’m a bit at a loss here. I’ve just deployed a new site on the excellent Netlify platform. But the javascript doesn’t seem to load/work. The site can be found here: https://stoic-brown-842f62.netlify.app/. And the source is on Github: GitHub - haarts/disknotifier.com-hugo

I’m migrating from a custom-even-more-static setup which is currently live at disknotifier [dot] com, where the javascript works.

You can see the javascript doesn’t work at, for example, the pricing toggle. I’m also using AOS (AOS - Animate on scroll library) which animates elements on scroll. These don’t work either.

The weirdest thing is that locally everything works. When I run locally with hugo server everything is dandy. But when I build the site with hugo and start a webserver in the generated public directory (I’m using caddy fileserver for that) it no longer does. (So it’s not an issue with Netlify.)

The Javascript console remains empty, with no obvious errors. And the main.js is present and I think it loads properly.

I’ve tried both Firefox and Chrome.

What else can I try?

Thanks in advance.

Is there perhaps a listener not called or something? And what could possibly be the difference between hugo server and hugo && cd public && caddy fileserver?
I’ve diff’ed the index.html and the main.js and there are no differences.

At the ends of my wits I diffed the CSS files. And lo and behold there’s a difference! It seems that the CSS files from the node_modules are included when running hugo server but not when I’m doing hugo. No idea why. Still open to tips.

I’ve found the issue. The hugo_stats.json doesn’t contain the AOS classes (and some others). Because of that, these are pruned when making a production build.

I don’t understand why this is.
Here’s my PostCSS file: disknotifier.com-hugo/postcss.config.js at master · haarts/disknotifier.com-hugo · GitHub

And my styles.scss: disknotifier.com-hugo/styles.scss at master · haarts/disknotifier.com-hugo · GitHub

I’ve seen something similar with Lightgallery. It is setting some of the classes only at runtime, so pruning removes them because they seem unused.

I ended up whitelisting a bunch of somethings:

const purgecss = require('@fullhuman/postcss-purgecss')({
    // see https://gohugo.io/hugo-pipes/postprocess/#css-purging-with-postcss
    // and https://github.com/dirkolbrich/hugo-theme-tailwindcss-starter
    content: [
      './hugo_stats.json',
      themeDir + '/hugo_stats.json'
    ],
    defaultExtractor: (content) => {
      let els = JSON.parse(content).htmlElements;
      return els.tags.concat(els.classes, els.ids);
    },
    safelist: [
      /cloak/,
      /aos/,
      /rtl/,
      /type/
    ]
})

The solution is far from optimal IMO, but I just don’t know how to obtain debug information from this process (do I put a console.log somewhere? I know little of JS).

You could refrain from purging.
As to debugging: This is out of scope here, but you can of course use the development console of your favorite web browser.

I’m using Tailscale. If I don’t purge the resulting CSS file is enormous!

As for debugging, I can’t run this PostCSS script in a browser. Can I? I don’t know.

There’s no point in running postCSS in the browser, since it already has run when you see the file in the browser. The interesting point here is: Does your DOM change after it has initially loaded, e.g. through a DOMContentLoaded handler or something like that.

On the other hand, you could ask yourself why you’d want to use a CSS framework that is „enormous“ if you don’t purge the stuff you do not need. If you only need very little of it why bother with the whole thing at all?

For more information on CSS, JavaScript etc. I suggest heading to Mozilla Developer Network (mdn).

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.