Allow use of ES6+ in vault and script

[m90]

We set off limiting the language features in JavaScript portions of the codebase to ES5 only as to not overcomplicate the build setup.

We already had to ditch this for the auditorium when migrating from Choo to Preact (which requires transpilation of JSX). Now, standard which Offen uses for linting mandates using const and let over var, so if we ever want to upgrade standard we'd have to allow this.

I think it'd be safe by now to add babelify to the build pipelines for script and vault and allow limited use of ES6+ syntax and idioms, which will also make the codebase more accessible to outside contributors.

When working on this it might be a good idea to compare the size of the bundles being output so that we don't accidentally introduce unneeded bloat that Babel sneaks in. We probably could not get away with using modern syntax entirely as otherwise we could not fail gracefully in old browsers, so at least the script would always need to be transpiled down.

[m90]

Doing this would also mean we can migrate the opt-in banner in the vault from nanohtml to using preact just like in the auditorium.

[m90]

Moonshot: start using esbuild instead. This would require porting l10nify and schemaify to esbuild-plugins however.

[mochaaP]

I'm interested in taking this. Assign me if you want :)

[m90]

As this issue is already a bit dated and also not terribly well scoped: what'd be an approach you'd feel comfortable with when working on this @mochaaP ?

[mochaaP]

I prefer esbuild, but could potentially be parcel/vite if you'd like to.

[m90]

esbuild sounds good to me as well. The most complicated part of moving the setup will probably replicating the browserify-based l10n pipeline that is currently using this https://github.com/offen/l10nify and which would need to be ported. The schemaify plugin has already been ported by myself: https://github.com/offen/esbuild-plugin-jsonschema

[mochaaP]

if you don't mind introducing a 3rd-party dependency: https://github.com/i18next/i18next & https://github.com/i18next/i18next-gettext-converter

I've done a (somewhat) similar i18n pipeline from scratch, but the string lookup is not preprocessed. https://github.com/bs-community/blessing-skin-server/blob/cleanup/resources/assets/src/scripts/i18n.ts

wdyt?

[mochaaP]

aside from that, do we have a certain browser target support range for 2024? (like a browserslist query or something)

[m90]

Hmm, that's a tough call. Considering thisi project is mostly in maintenance mode right now, I'm not sure if it makes sense to swap out the l10n setup - which sounds like a bigger undertaking - unless it actively causes problems. Adding support for having Es6+ features in all JS would still be nice even in maintenance mode, but maybe the solution for now would just be to add this to the existing Browserify pipeline?

[mochaaP]

Hard to say, but I'd prefer to rework this for better maintainability.

[mochaaP]

The current browserify pipeline is in a very strange shape - it doesn't even build on my machine.

[m90]

it doesn't even build on my machine.

Are you on a Mac / ARM processor and this is #818 or is it another issue that prevents the build?

[mochaaP]

No. I'm on Linux x86_64, Node v20.11.1 & npm 10.5.0.
It's basically another dependency hell.

Downgrading to an older version could work, but it doesn't make much sense since we're refactoring it.

[m90]

But does it build in Docker for you? The setup is not really expected/designed to run outside of Docker?

[mochaaP]

Ugh, I believe Node 16 is already EOL? And I confirm I'm doing the exact steps as described in the Dockerfile, so it should work.

[mochaaP]

And no, it does not build in docker for me either.

[mochaaP]

Considering this project is mostly in maintenance mode right now

I could potentially try to revive this with some efforts, if you don't mind all the refactoring / breaking stuff etc. and accept those contributions. There are still quite some places for discussion tho.

[m90]

I believe Node 16 is already EOL?

I don't have the resources to participate in the constant update cycle unfortunately and since this is just used for bundling a client side app, I would guess it's fine to stick to that version.

And I confirm I'm doing the exact steps as described in the Dockerfile, so it should work.

If you use different versions, why should it work? It's important to understand the current directory layout requires use of npm at version 6 because of npm/cli#2339

---

I could potentially try to revive this with some efforts, if you don't mind all the refactoring / breaking stuff etc. and accept those contributions. There are still quite some places for discussion.

I'd be happy to hear about what exactly you would like to do. I do have to say that I'd probably reject efforts that are doing nothing but update pipelines to something that is newer than what's in use without having any user facing effect.

If you have ideas for improvements that go beyond that, I'm happy to discuss these.