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

The "defines" js.Build option fails silently for almost anything besides single alphanumeric words #8040

Closed
LandGod opened this issue Dec 11, 2020 · 4 comments

Comments

@LandGod
Copy link

LandGod commented Dec 11, 2020

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.79.0/extended windows/amd64 BuildDate: unknown

Does this issue reproduce with the latest release?

Yes.

Summary

When using the "defines" option with js.Build many special characters such as -, <, and !, as well as any internal spaces, will cause js.Build to return a nil reference without throwing any error. The build will later fail when you try to insert the link to the resource into your layout file with $myBuiltJS.RelPermalink.

EG:

Error: Error building site: failed to render pages: render of "home" failed: "C:\Users\Dan\Documents\Programming\HugoTest\quickstart\layouts\index.html:47:31": execute of template failed: template: index.html:47:31: executing "main" at <$testJs.RelPermalink>: error calling RelPermalink: runtime error: invalid memory address or nil pointer dereference

The issue is two-fold here:

  1. js.Build just fails so easily that it's really hard to use it for anything other than the very most basic substitutions. I assume (and hope) that this is not the intended behavior.
  2. Because no error is thrown from js.Build itself, the resulting build failure is very confusing and there is no easy way to tell that a) The problem even came from "defines" in the first place, and b) what about the provided value to "defines" caused it to fail.

I spun up a fresh Hugo repo to demonstrate this issue. Check out the index.html layout to see various exampled of passing and failing values for "defines". (You'll have to un-comment each one individually to see.)

https://github.com/LandGod/HugoTestBed

@LandGod LandGod changed the title The "defines" js.Build option fails silently for almost anything besides single alphanumeric strings The "defines" js.Build option fails silently for almost anything besides single alphanumeric words Dec 11, 2020
@bep bep added the Bug label Dec 11, 2020
@bep bep added this to the v0.80 milestone Dec 11, 2020
@bep
Copy link
Member

bep commented Dec 11, 2020

This smells like an upstream issue (in the ESBuild project) -- we just pass these defines on as-is -- and I would somehow expect them to validate these.

@bep bep modified the milestones: v0.80, v0.81 Jan 2, 2021
@evanw
Copy link

evanw commented Jan 3, 2021

I was curious to see what this problem was so I took a look. It looks like the code for processing errors from esbuild tries to access msg.Location.File without checking for nil first:

loc := msg.Location
path := loc.File

I assume this then leads to a crash in Hugo's code: runtime error: invalid memory address or nil pointer dereference. The Location field in esbuild's API is deliberately a pointer to a struct instead of a plain struct because it can be nil. This corresponds to an error that isn't associated with a file. In this case the error is with the API options so there is no file location and the location is nil.

When using the "defines" option with js.Build many special characters such as -, <, and !, as well as any internal spaces, will cause js.Build to return a nil reference without throwing any error.

The define feature is documented here: https://esbuild.github.io/api/#define. The key must be a valid JavaScript identifier or identifier chain, and the value must either be a valid JavaScript identifier or a JSON value.

@bep bep modified the milestones: v0.81, v0.82 Feb 19, 2021
@bep bep modified the milestones: v0.82, v0.83 Mar 21, 2021
@bep bep modified the milestones: v0.83, v0.84 May 1, 2021
@bep bep modified the milestones: v0.84, v0.85 Jun 18, 2021
@bep bep modified the milestones: v0.85, v0.86 Jul 5, 2021
@bep bep modified the milestones: v0.86, v0.87, v0.88 Jul 26, 2021
@bep bep modified the milestones: v0.88, v0.89 Sep 2, 2021
@bep bep modified the milestones: v0.89, v0.90 Nov 2, 2021
@bep bep modified the milestones: v0.90, v0.91.0 Dec 13, 2021
@bep bep removed this from the v0.91.0 milestone Dec 22, 2021
@bep bep added this to the v0.109.0 milestone Dec 14, 2022
@bep bep modified the milestones: v0.109.0, v0.111.0, v0.110.0 Jan 26, 2023
@bep bep modified the milestones: v0.111.0, v0.112.0 Feb 15, 2023
@bep bep modified the milestones: v0.112.0, v0.113.0 Apr 15, 2023
@bep bep modified the milestones: v0.113.0, v0.115.0 Jun 13, 2023
@bep bep modified the milestones: v0.115.0, v0.116.0 Jun 30, 2023
@bep bep modified the milestones: v0.116.0, v0.117.0 Aug 1, 2023
@bep bep modified the milestones: v0.117.0, v0.118.0 Aug 30, 2023
@bep bep modified the milestones: v0.118.0, v0.119.0 Sep 15, 2023
@bep bep modified the milestones: v0.119.0, v0.120.0 Oct 4, 2023
@bep bep modified the milestones: v0.120.0, v0.121.0 Oct 31, 2023
@jmooring
Copy link
Member

This was resolved in v0.81.0 with a1fe552.

Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Dec 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants