Minified JS not getting built

I have a hugo site deployed at : learnings.desipenguin.com (Netlify instance name : dazzling-brown-05d5eb)

The site uses Jane theme (I don’t think matters, but just in case)

I have modified some sccs files (like _variables.scss) - these are “compiled” into jane.min.css (with some string in between like sass/jane.min.f4d8f29954081ee0de667765d4b2fbf245294b6b96ffeb5002400996db0fdf6c.css)

When I build the site locally via hugo command, the above file is “regenerated” because of changes to the sccs file, and my changes are reflected. See here such manually deployed site.

Content wise, this site is identical to Archive - Learn. Share. Improve - you can see the visual difference though. i.e. For Archive - Learn. Share. Improve, the default color is reddish, while I have selected “blue” in the sccs file (reflected in Archive - Learn. Share. Improve)

Other visual differences are also due to the same reason (i.e. no line separator, smaller font etc.)

I tried “Clear cache and regenerate” build option, but that did not help.

Any suggestions ?

You have one stylesheet and one external JavaScript file that are not “found.” Without plunging into your code, you have links to a CSS and a JS file on Cloudfront.net, which means this may not be a Netlify issue. Not understanding why you compile your CSS and JS files in your build, and then host them elsewhere. Wouldn’t it be simpler and easier to host all your site files on Netlify?

Greg,

Thanks for responding. I’ll look at references to Cloudfront.net that you mentioned.
I am not doing anything different. This could be part of Jane theme. (I have a local copy, rather than git submodule, cause I want to make changes)

Locally, I just run hugo command - no additional commandline params - and I see updated minified file in my public folder. (I then deploy the same as-is on mandarvaze.bitbucket.io/)

Even when I run hugo server --disableLiveReload locally for testing, I see the changes from scss file being reflected.

I somehow suspect some kind of caching. But unable to pin point.

BTW, you can look at my “code” (which are just markdown files and hugo config etc) here

Thanks once again

I did not find text cloudfront.net in the output generated by hugo command. See here

I did find references to cdnjs.cloudflare.com, but that is commented and is under if lte IE9 (which is not the case)

The “generated” output can be found here

Looking at the view sources, I see the following :

Good site contains : <link rel="stylesheet" href="/sass/jane.min.f4d8f29954081ee0de667765d4b2fbf245294b6b96ffeb5002400996db0fdf6c.css" …`

bad site contains : <link rel="stylesheet" href="/sass/jane.min.af20b78e95c84de86b00a0242a4a77bd2601700e1b250edf27537d957ac0041d.css" ......

Both these are local

BitBucket does not allow me to see those files, but now your site seems to be loading everything and displaying properly, so you seem to have found and resolved the issue(s).

Issue is not resolved :cry:

See Archive - Learn. Share. Improve (This is what I want. This is just hugo public folder generated locally, uploaded as-is)
Vs
Archive - Learn. Share. Improve (Problem - this is via netlify)


I’ve marked both bitbucket repos as public, so these should be accessible to you now.

Got into the repository. Thank you.

I can see the differences in the CSS files, and I can see what you mean about the text color differences between the two versions, but there is another difference, too: the date format. It doesn’t seem as though that should have spelled the difference between building and failing, but you might look into that, too, as it must be more than a CSS change.

Just spit-balling here. I’m out of ideas.

Fixed the date format issue. I have two branches, netlify and master, they were out of sync a little (only dateformat variable in config.toml)

Anyway, now that you can access the repos - the lines that matter are:

  1. Cobalt Blue
  2. Archive padding, border etc

As I mentioned these changes should reflect in jane.min.<...>.css, but they don’t - on netlify. - work locally.

Hey @mandarvaze, thanks for sharing all this info about your setup. One thing that may be an issue is that you have a netlify.toml deeeep within your themes/ directory on the “netlify” branch. Could you try bringing that out to your directory root, or leaving it out of a deploy altogether and seeing what happens? You may have all the settings you need configured it in the UI.

I am not sure if the contents of that file would impact the behaviour we are seeing.

$ cat ./themes/jane/netlify.toml
[build.environment]
  HUGO_VERSION = "0.55.6"
  HUGO_THEME = "repo"
  HUGO_BASEURL = "/"%

Irrespective, I’ll remove it - cause I don’t think it is being used anyway.

sounds good. Let us know if that changes anything.

Didn’t help :frowning:

Hi, @mandarvaze, there is something unusual happening with that site. Would you please test making at new Netlify site in the same account and then linking that new site to the same repo, set the HUGO_VERSION environment variable to the same value, and make the production branch the same (netlify)?

I believe the new site will show the correct CSS. If you do this, will you please send us a link to the new site (and don’t delete it until we examine it)? Also please note the link to the Archives will direct you to the custom domain which will be the wrong site. You’ll need to manually navigate to https://new-netlify-subdomain.netlify.com/post/ to see it.

1 Like

@luke You are on to something here. Definitely a step is the right direction. I hope this gives you enough data to troubleshoot further.

See Archive - Learn. Share. Improve (Same site deployed via new netlify instance)

Vs

Archive - Learn. Share. Improve (Original site for which the problem was reported)

I still think this is related “some caching somewhere”.

When I create new site, there is nothing to cache.

I wonder if I might run into similar problem when I update sccs files and new jane.min.css is not generated.

I can use this as a “workaround” - in case you can not find the root cause.


BTW, I have exact same problem elsewhere also - So I don’t think this is “one off” case.

Vs

I have not created a new site for this one, but I suspect new site will “solve” the issue.

One more thing to try to add to @luke’s suggestions: you may want to rm -rf the resources/ directory inside the theme folder. It was difficult for me to find much information about this directory in the Hugo docs, but it seems to cache generated assets and I wonder if it’s clashing or creating hard-to-track issues when you change styles.

@jen Removed. Did not help. I get this error when building my problematic blog

As suggested by @luke, the same codebase triggers builds for two netlify instances. The second/newer one was built fine.

I wonder why the existence of resources folder did not matter for Archive - Learn. Share. Improve (New instance as suggested by @luke)

Similarly, why does it not matter for local development server, as well as locally generated public folder generated by hugo command.

@mandarvaze - thanks for continuing to work on this. Unfortunately, we’ve been puzzling over this just as much as you have, and we’re really not sure what is causing this behaviour.

I want to suggest that you chat with folks in the Hugo forums, maybe they have thoughts on this:

We’ll continue to keep thinking about this, and if we have any other thoughts we’ll post em here. Sorry to not have better news.

@perry The problem is not seen locally when I run hugo command.
Moreover, when I created new netlify instance, (as suggested by @luke) - we did not see the problem.
The problem does not seem “one off” as well. As I mentioned, I have another site which uses same theme with hugo, where the problem is seen as well. (I didn’t create new instance for that. I could. But I think we won’t see the problem there)

So I am not sure if the problem is with hugo itself.

Moreover, this may be theme specific as well. I’ll ask there, but I’m afraid they might say “not hugo related”.

I want to thank everyone who tried to suggest and troubleshoot this.

At least I have a workaround (Once again thank @luke) - Let us keep thinking about this.

1 Like