Hugo: Support for ES6 JavaScript transpilation using Babel.

[hmmmmniek]

Issue related to #5587

Copied from my post on the forum:

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.

• https://github.com/dop251/goja (MIT License)

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?

I already got Goja working in a local build.
So now the last step is to somehow use to Babel CLI in the hugo project.

I noticed that we already use the postcss CLI in HUGO.

So currently my plan is to basically follow the example of how postcss is implemented, I will:

• Create a new directory resources/resource_transformers/transpileJS
• Create transpileJS.go, in which I will:
  
  
  
  • Load the goja library for interpreting JavaScript code.
  
  
  • Load the Babel cli in the exact same way as how it is done here.
  
  
• Update snapcraft.yaml to include the babel CLI as well besides the postcss CLI.

I would love to get your opinion on this @bep , since you wrote the postcss functionality. Do you think this is a good approach? Also, please let me know if you think there is a step I am missing.
I plan to work on this tomorrow or the day after tomorrow.

[bep]

In isolation, I don't think this is something that I see included in Hugo. I may change my mind on this down the road, esp. considering if we can get some "resource plugin" support so these can be managed outside of the Hugo mono repo. But I cannot give you any better answer than that right now.

[hmmmmniek]

Okay, thanks for your response.
I will implement this feature in a forked repo in any case, because I need this functionality for my own project.
I'll create a PR for this when its done, whether or not you'll accept this PR then is up to you :)

[westurner]

5772 mentions that you need test cases. Where do those go? What a great feature.

[bep]

I am developing a documentation website for a JavaScript library.

Could anyone come up with some good arguments why this would be really useful for many Hugo users?

[westurner]

5039 "Add support for Babel in resource pipelines" (marked stale) has 15 upvotes?

Personally, I'd like to add some JSX with React (e.g. forms with validation https://github.com/mozilla-services/react-jsonschema-form (*)) and managing that part of the build with a separate tool seems unnecessary.

[bep]

It would help sell this feature if someone could create a small demo-app with a React or Vue component or something that demoed how this would work with the related PR.

[carlmjohnson]

Here is a different thought:

Every browser except < IE11 supports ES6+. On the other hand, many users for various reasons have to disable Javascript (e.g. Opera Mobile, search engines, disability workarounds, etc.). Remember also that the number of users of IE11 and below will only go down over time, but the number of users who disable JS entirely can be expected to stay roughly the same. So, I think it's entirely fair for a new site to say "this site has basic functionality without JavaScript, but if you want advanced functionality, you must use a browser that supports ES6++."

To that end, I think Pikapkg represents a good approach of using <script type="module"> to keep older browsers from downloading JS they cannot use.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.