ESM/CSJ build & dependency reduction

[lukashroch]

Description

• tsc build process changed to use tsup - ESM/CJS support
• bump eslint config to flat file config (legacy deprecated)
• bump all dependencies -> clean audit with no security issues reported
• swap JWT lib implementation from jsonwebtoken to jose - supports ESM/CJS, treeshakable, wide range of envs and no dependencies (solved Using in Vite/Vue3 App Throws 'Uncaught TypeError: util.inherits is not a function' #15, jsonwebtoken uses jws and other deps which rely on couple of node libs)
• read pkg version directly and use tsup to extract version, which is used as constant in build-file, so fixes NextJS ENOENT: no such file or directory Error when trying to create Client #36
• migrate to pnpm (faster and better deps tree resolution, npm already had some issues... ) and used lib build for example directly, github actions adopted to pnpm too
• migrate to vitest

Motivation and Context

• out-of-date both runtime and dev dependencies
• missing support for modern JS/TS stack -> CJS/ESM builds & corresponding types
• attempt to properly fix couple of issues related due to use of tsc only (Using in Vite/Vue3 App Throws 'Uncaught TypeError: util.inherits is not a function' #15, NextJS ENOENT: no such file or directory Error when trying to create Client #36 )

How Has This Been Tested?

• all tests passing
• ESM/CJS types tested/passed with https://arethetypeswrong.github.io

 | "@duosecurity/duo_universal"
node10 | ✅
node16 (from CJS) | ✅ (CJS)
node16 (from ESM) | ✅ (ESM)
bundler | ✅

Types of Changes

• Breaking change (fix or feature that would cause existing functionality to change)

Function client.createAuthUrl('username', 'state') now returns a promise.

// before
const authUrl = client.createAuthUrl('username', 'state');

// after
const authUrl = await client.createAuthUrl('username', 'state');

Drop Node.js 18 -> EOL

• use at least Node.js 20 LTS

[lukashroch]

Hi @jeffreyparker @AaronAtDuo ! any chance to review this and have your thoughts on this? Happy to work through any details and make necessary adjustments.

[AaronAtDuo]

Taking a look

[lukashroch]

Thanks @AaronAtDuo

I have replaced couple of additional node deps with globalThis access to make it more env-agnostic. However crypto is only available in globalThis from node19, so this would mean dropping node18 support. Though might not be a bit issue since node18 is EOL this month.

[AaronAtDuo]

this would mean dropping node18 support.

This seems fine to me with the EOL coming up, especially given a question I'll get into momentarily.

I'm very far from being a JS/TS expert so please bear with me if these are dumb questions:

• If we stop using npm (the build system) would we still use npm (the package repo) for publishing the library?
• I assume the switch from sync to async code would be backwards incompatible? So, following semver, this would be a major version bump? I'm not against that - I know async is the new hotness - but I just want to make sure I'm understanding the ramifications.

[lukashroch]

thank you @AaronAtDuo for having a look at this!

If we stop using npm (the build system) would we still use npm (the package repo) for publishing the library?

We're swapping only package manager from npm to pnpm, registry is still the npm one, so nothing would change there. I have adjusted github action to use pnpm, publish commands etc are all the same.

Since you mention this, there is new open source registry getting quite a lot a traction in community - JSR (https://jsr.io), you might consider publishing the package to this one too? I think it would just few lines in github action and for you to set up account there in case you'd like to do that.

I assume the switch from sync to async code would be backwards incompatible? So, following semver, this would be a major version bump? I'm not against that - I know async is the new hotness - but I just want to make sure I'm understanding the ramifications.

Yes, it is indeed a breaking change along with dropping Node.js 18 in a semver sense. Swap to async for that method was not much about async being trendy, it's just that jose signing function is async/non-blocking, while the original jsonwebtoken had it sync (or rather callback-based).

I have update the PR description to include node.js 18 drop also updates dependencies to reflect this.

[lukashroch]

@AaronAtDuo @jeffreyparker Hi both, I was wondering if you had a chance to give this a look? Happy to work through any further required changes.

[AaronAtDuo]

@lukashroch Finally getting back to this, sorry for the delay. First thing, just looks like some merge conflicts popped up. Also, we noticed that this diff seems to have undone a package file fix in https://github.com/duosecurity/duo_universal_nodejs/pull/30/files?

[lukashroch]

@AaronAtDuo thank you for reviewing!

I have now resolved the conflicts that accumulated over time and bumped all deps as it was stale for a bit.

Re package file fix: Yes, it was intentional to 1) get rid of the usage of node.js libs to be more env agnostic, 2) also it should not be needed, build system extracts it const now, so there shouldn't be a need to import package.json file like this.

if you have a look into the build artefacts, you'll see it like this:

var version = "2.1.0";

[AaronAtDuo]

@lukashroch I'll try to get a (major version) release out within the next couple of days. Thanks so much for your contributions - and patience!