How to deal with webworker urls in js.Batch?

support
1

Howdy,

I’m currently trying to convert a project from a messy `js.Build` setup to a more streamlined js.Batch configuration. The old build uses several `js.Build’ calls to split the code into several parts and employs the `@params` systems for communication between them. A common use case is a WebWorker that needs the script url. The fingerprinted url is passed through that way.

Unfortunately that does not seem to work with `js.Batch`. When I try to extract the url, the build breaks as many files are no longer build:

{{- with .Group "main" -}}
  {{- $gr := . -}}
    {{- range resources.Match "js/main.js" -}}
      {{- $file := resources.FromString "js/x-main.js" .Content -}}
      {{- $worker := index (index $batch.Build.Groups "search-worker") 0 -}}
      {{- with $gr.Script (path.Base $file.Name) -}}
        {{ .SetOptions (dict "resource" $file) }}
      {{- end -}}
  {{- end -}}
{{- end -}}
...

Is this something that has already come up and a common solution is established?

I’ve read that `esbuild` should be able to handle this use case by using URLs that are automatically transpiled correctly when hashing is applied, but the Hugo integration does not seem to support that. Thanks.

2

Where have you read that? A link would be great.

This is the issue I have read WebWorker support? · Issue #312 · evanw/esbuild · GitHub

So, currently I suspect you need to do something ala hugoTestProjectJSModImports/assets/js/main.js at 7d79d6b7234028ca508d11fcb540ff5b299ecc00 · gohugoio/hugoTestProjectJSModImports · GitHub

When thinking about this, i think we could possibly do a better job of supporting this in js.Batch, but that’s non-trivial and not on my TODO list at the moment.

3

esbuild standalone seems to be able to perform the necessary replacements when hashing during deployment according to the OP.

EDIT: On 2nd thought, might be specific to angular though.

Understood. As always, thanks much for your support!

4

No, none of the issues I’ve seen points at a released fix for this. Theres:

5

@bep Thanks much for the pointers. Maybe the Angular integration addressed this issue specifically.

I was thinking that maybe I could use the `defines` feature to workaround the problem, but I could not make it replace anything. I might be doing something fundamentally wrong. Do you happen to have a github repo for this use case that I could study? Thanks.

6

See GitHub - bep/hugo-webworkers-test: A test repo. · GitHub

7

Awesome! Fingerprinting is the crux here. There currently seems no way to get that working within one `js.Batch` call. I hope your experiment is successful and you can roll it out soon. Thanks again!

8

This needs to be fixed in ESBuild. See my comment in WebWorker support? · Issue #312 · evanw/esbuild · GitHub

There may come a time when we could start maintaining a “soft fork” of ESBuild with some patches (we’re lucky in the sense that we only depend on ESBuld as a Go dependency, so that would be straight forward on the technical side), but we’re not there yet.

9

Thanks much for taking the time to investigate and instigating a solution.

I don’t know jsbuild in detail, there might be workarounds when used standalone. For `js.Batch`, it’s a showstopper for my use case. Otherwise a very nice addition that could streamline my build quite a bit. Keep up the great work!

10

So, I do agree that solid webworkers tuff is very important, which is why I’m a little bit surprised that the upstream issue is 4+ years old.