Support for browser-compatible JavaScript compilation

feature
1

I am developing a documentation website for a JavaScript library.
On this website we offer live code examples which are written in ES6 JavaScript because this allows us to write very clean an easily understandable code.
However, ES6 is not a widely supported JavaScript version, especially IE11 does not, and will not support this.

Currently, we load Babel-standalone libraries and transpile the code examples client side as a temporary solution for better browser compatibility.
Of course, this is definitely not an ideal solution, these libraries are about 3.5Mb in size, and were never really meant to be used in this way.

A better solution would be to transpile the ES6 JavaScript code during website generation.
This feature will not only be useful for my very specific use case. But it would also allow anyone to write ES6 code for their hugo website, while keeping the website compatible with browsers that do not support ES6.

This feature will introduce a new dependencies:
First, we need a library which allows us to interpret JavaScript code, goja seems like a good choice.

Besides that, we will need a library which allows us to transpile ES6 code. Babel is a widely used JavaScript library which does this very well

  • https://babeljs.io/ (MIT License)
    We will have to figure out how to properly include a JavaScript dependency into HUGO, but I’m sure I’ll figure something out.

My plan is to use goja to load the babel library. Then the babel library can transpile a JS code string passed by the HUGO user.
For example, you’d use this function like this:

{{ $jsCode := "[1, 2, 3].map(n => n ** 2);" }}
{{ $jsCode | transpileJS "ES5" }}

Which will produce the following browser-compatible output:

[1, 2, 3].map(function (n) {
   return Math.pow(n, 2);
});

I will make an attempt to implement this new feature somewhere in the next week.
I’d love to get some opinions on this, do you agree with this approach or do you feel like I’m making this unnecessarily complex?

1 Like
2

Hi @hmmmmniek,

I would personally love to see something like this handled directly by Hugo Pipes.

Have you created it an issue in GitHub? I suggest you do so with as much explanation about the way you want to implement this (what you did here I guess).

3

Also a few issues worth taking a look at: https://github.com/gohugoio/hugo/issues?utf8=✓&q=is%3Aissue+is%3Aopen+babel

4

@regis , thanks for your response.
Last Friday, I spend an afternoon on this, getting familiar with the HUGO source code and GoLang in general (never worked with Go whatsoever, so implementing this is also a fun challenge for me personally).
I got the building environment set up and managed to get the JavaScript interpreter (Goja) working already.
Monday I will spend some more time on this. The next step is to somehow include babel as a dependency. Which might be tricky, as it is not a Go package, so I cant include this dependency the conventional way.
Once I figure out how to do that, then that’s it! Finalizing the implementation at that point should be very simple.

I’ll create an issue for this on Monday.

1 Like
5

Update on this topic.
I just created a pull request in the repo for this feature.
You can give it a :+1: if you like this feature, that might help convince the maintainers to accept it :wink:

1 Like
6

That’s great! I am pretty sure I will use this once/if this ever gets accepted. It would be cool if it was possible to specify the location of a babel config file similar to the postcss options.

7

good idea, i can try to implement that this weekend and update the pull request. For some reason one of the Travis ci checks failed, so I have to take a second look at this anyway.

Update: @holehan I already found some time to update the pull request to include to possibility to use configuration files (.babelrc/babel.config.js/any custom path)

1 Like