chore: update node and dependencies

[TimoGlastra]

This PR:

• deprecates Node.JS 18 (reached end of life)
• adds support for Node.JS 24
• Updates a lot of the dependencies

Not all dependencies are updated, as some require a bit more work (such as epxress 4 to 5), or require ESM (i would still like to transform Credo to ESM only as well, as it seems to be more and more packages are ESM only. Maybe for 0.7).

I also updated pnpm and moved all deps that are used multiple times to the catalog, so we can ensure all packages are in sync.

It seems the pnpm-lock was cleaned up quite a bit, probably due to updating (so all packages are more aligned) and the catalog

[changeset-bot]

🦋 Changeset detected

Latest commit: 5d7713b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 15 packages

Name	Type
@credo-ts/indy-sdk-to-askar-migration	Minor
@credo-ts/question-answer	Minor
@credo-ts/react-native	Minor
@credo-ts/action-menu	Minor
@credo-ts/redis-cache	Minor
@credo-ts/anoncreds	Minor
@credo-ts/openid4vc	Minor
@credo-ts/indy-vdr	Minor
@credo-ts/didcomm	Minor
@credo-ts/tenants	Minor
@credo-ts/askar	Minor
@credo-ts/cheqd	Minor
@credo-ts/core	Minor
@credo-ts/drpc	Minor
@credo-ts/node	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[genaris]

Nice usage of catalog feature (didn't know about it!).

I agree that migrating to ESM module is a must nowadays. Let's schedule it for 0.7!

[TimoGlastra]

Node.JS 24 seems tricky. The CI is having issues with the forks of ref-napi. Looking into it, it depends on really old versions of node-addon-api (3.x while 8.x is released).

So we can't support Node.JS 24 until we resolve this.

@genaris @berendsliedrecht any thoughts on how to resolve this. We're depending on deprecated/forked versions of these libs. Is there another library / approach we can use for Node.JS FFI wrappers that are more modern?

[TimoGlastra]

Claude recommends:

• koffi
• ffi-rs
• WASM

https://claude.ai/share/6a52dd6f-5d53-4aeb-bb8f-ae90d6644102

Both koffi and ffi-rs look promising to me. ffi-rs seems somewhat similar to how the python wrappers are written as well? koffi looks cool

[TimoGlastra]

I reverted the Node 24 additions for now, we can look at that later (and support Node 20 and 22 for now)

[berendsliedrecht]

Both koffi and ffi-rs look promising to me. ffi-rs seems somewhat similar to how the python wrappers are written as well? koffi looks cool

I would have to see if ffi-rs has all the functionality to replace ref-napi and if so, that would be a good upgrade. koffi has quite some inline ASM and is written in C, so I would like to avoid that.

[berendsliedrecht]

I made an example with node-ffi-rs and it works quite well. It will require quite some work again to overhaul everything (anoncreds and askar).

import {
	DataType,
	open,
	close,
	define,
	funcConstructor,
	createPointer,
	freePointer,
	PointerType,
} from "ffi-rs";

open({
	library: "libfanta",
	path: "../rust/fanta/target/debug/libfanta.dylib",
});

const Adder = {
	lhs: DataType.I32,
	rhs: DataType.I32,
	ffiTypeTag: DataType.StackStruct,
};

const AdderWithFunc = funcConstructor({
	paramsType: [DataType.I32, DataType.I32],
	retType: DataType.I32,
});

const library = define({
	add: {
		library: "libfanta",
		paramsType: [DataType.I32, DataType.I32],
		retType: DataType.I32,
	},
	add_with_struct: {
		library: "libfanta",
		paramsType: [Adder],
		retType: DataType.I32,
	},
	add_with_callback: {
		library: "libfanta",
		paramsType: [DataType.I32, DataType.I32, DataType.External],
		retType: DataType.I32,
		runInNewThread: true,
	},
});

const callback = (lhs: number, rhs: number) => {
	const val = lhs + rhs;
	freePointer({
		paramsType: [AdderWithFunc],
		paramsValue: ptr,
		pointerType: PointerType.RsPointer,
	});
	return val;
};

const ptr = createPointer({
	paramsType: [AdderWithFunc],
	paramsValue: [callback],
});

void (async () => {
	console.log(library.add([1, 2]));
	console.log(library.add_with_struct([{ lhs: 12, rhs: 88 }]));
	console.log(await library.add_with_callback([10, 50, ptr[0]]));
})();

close("libfanta");

#[repr(C)]
pub struct Adder {
    lhs: i32,
    rhs: i32
}

#[unsafe(no_mangle)]
pub extern "C" fn add(lhs: i32, rhs: i32) -> i32 {
    lhs + rhs
}

#[unsafe(no_mangle)]
pub extern "C" fn add_with_struct(s: Adder) -> i32 {
    s.lhs + s.rhs
}

#[unsafe(no_mangle)]
pub extern "C" fn add_with_callback(lhs: i32, rhs: i32, s: &unsafe extern "C" fn (lhs: i32, rhs: i32) -> i32) -> i32 {
    unsafe { s(lhs, rhs) }
}

This is equivalent to I think 99% of the functionality we need.

[TimoGlastra]

Oh very nice!! I think we can get quite far with AI to rewrite the native modules if we have the needed scaffolding and examples and provide it with the current ffi wrapper.

We do need to think what to do with indy-vdr as it will give issues. Should we not make it available starting from node 24? So it can be used with node 20/22 only?

Should we move it to another repo at some point if we can't make it work with all versions anymore?

cc @swcurran

[berendsliedrecht]

Oh very nice!! I think we can get quite far with AI to rewrite the native modules if we have the needed scaffolding and examples and provide it with the current ffi wrapper.

We do need to think what to do with indy-vdr as it will give issues. Should we not make it available starting from node 24? So it can be used with node 20/22 only?

Yeah I think that that is likely. We sadly don't have the resources to update it.

Should we move it to another repo at some point if we can't make it work with all versions anymore?

I think we can mark it as deprecated if no one is willing to pick it up. And also remove it from the release pipeline.