Add ESM support

[SvanteRichter]

This is a pretty small change (looks large because it includes the generated files) that adds an export into ESM (also known as es6 modules).

I couldn't figure out where the minified build jobs are triggered, but the build-esm job should probably be added there too (or is it done manually when a release is done?).

I think this meets the minimum to fix #170.

I didn't think this was large enough the warrant an AUTHORS.md inclusion, but let me know if that is needed/warranted.

It can probably be done a lot better in the future, but this was the least invasive way I could think of.

[dchest]

Awesome, thanks!

Yes, everything is built manually.

Is there a way to test it? Manually, or in an automated way.

[dchest]

This unfortunately pollutes global scope. Perhaps, I should move all this modularization stuff into a a build step, like I did here: https://github.com/dchest/fast-sha256-js

[SvanteRichter]

I don't quite understand what you did in fast-sha-256-js though. I thought exports in ESM were reserved for the top level as they are statically resolved, not dynamic. Would that still work as a direct import in a browser?

[dchest]

Yeah, they are for CommonJS, but this can also be used when directly included using <script> tag.

[SvanteRichter]

I meant for ESM (edited my comment before I saw you reply), can ESM export be dynamic or non-top-level?

[dchest]

Ah, no I don't think it can be dynamic.

[SvanteRichter]

My hope is to be able to use this in a browser without any build step, so if that is possible while still keeping test and code duplication at an okay amount that'd be awesome.

If not I'll make it so some other way 🙂
Thanks for looking at and considering this!

[dchest]

Indeed, thanks! I think I'll make a special build step that will insert those things and generate .mjs files.

[SvanteRichter]

Is there a way to test it? Manually, or in an automated way.

I've been testing it by manually modifying the tests mostly, I didn't want to be too invasive and changing the whole testsuite. For example this for a hash test:

import nacl from './nacl-fast.mjs';
import util from 'tweetnacl-util';
import test from 'tape';
nacl.util = util;

var enc = nacl.util.encodeBase64,
    dec = nacl.util.decodeBase64;

let randomVectors = /* insert/import ./data/hash.random.js here */

test('nacl.hash random test vectors', function(t) {
  randomVectors.forEach(function(vec) {
    var msg = dec(vec[0]);
    var goodHash = dec(vec[1]);
    var hash = nacl.hash(msg);
    t.equal(enc(hash), enc(goodHash));
  });
  t.end();
});

I think the problem is how to keep CommonJS compatability while still running tests on ESM files, especially when tests themselves include certain dependencies. One solution would be to build separate versions and then run tests against those, but that sort of defeats the purpose of having native modules.

Please let me know if you have an idea on how I can keep compatibility but still test ESM though, that'd be great :)

[dchest]

Thanks, I'll figure something out for testing.

[Saiv46]

Any progress?

[SvanteRichter]

Closing since this is probably not getting merged and there are probably better (but also more invasive) ways to do it.

[rozek]

Thank you very much for your changes - although they did not make it into the original code, they still allowed me to make tweet-nacl.js ESM compatible in my own fork within a few minutes!

[SvanteRichter]

@rozek No problem, nice to see somebody using it! Seems like there are a couple of different forks that have done this now, maybe list yours also on #170.