fix: fix typing issues with typescript 4.9

[TimoGlastra]

Updates typescript to 4.9.4, and also updates some related dev dependencies.

Haven't updated any non-dev dependencies (that should be done separately as mentioned in #1213).

Fixes #1205

There were some issues specific to the latest TypeScript release which broke the types of AFJ. Mainly I've made the followign changes:

• update ts to 4.9.4
• Add @types/express to dependencies in @aries-framework/node. TS will complain that it can't find the types otherwise.
• Due to the update of eslint and typescript-eslint the order of imports have changed. Not sure why, but there's no functional change to the code
• Simplifies and changed the broken types in the credentials api.

[codecov-commenter]

Codecov Report

Merging #1214 (a2200a6) into main (c697716) will increase coverage by 0.08%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main    #1214      +/-   ##
==========================================
+ Coverage   87.59%   87.68%   +0.08%     
==========================================
  Files         734      734              
  Lines       17400    17535     +135     
  Branches     2928     2928              
==========================================
+ Hits        15242    15376     +134     
- Misses       2016     2017       +1     
  Partials      142      142              

Impacted Files	Coverage Δ
...ages/action-menu/src/services/ActionMenuService.ts	96.59% <ø> (ø)
packages/core/src/agent/Agent.ts	95.79% <ø> (ø)
packages/core/src/agent/AgentConfig.ts	95.65% <ø> (ø)
packages/core/src/agent/AgentModules.ts	100.00% <ø> (ø)
packages/core/src/agent/BaseAgent.ts	95.29% <ø> (ø)
packages/core/src/agent/EnvelopeService.ts	100.00% <ø> (ø)
packages/core/src/agent/Events.ts	100.00% <ø> (ø)
packages/core/src/agent/MessageReceiver.ts	82.30% <ø> (ø)
packages/core/src/agent/MessageSender.ts	86.47% <ø> (ø)
packages/core/src/agent/TransportService.ts	100.00% <ø> (ø)
... and 224 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[genaris]

It seems that type imports in eslint-plugin-import are a relatively recent feature, and they were doing some tweaks on their handling between 2.26.0 (the one we use) and 2.27.4 (the latest one). I don't see a specific reason why now it expects sibling types to be before parent ones, but anyway it is handling 'type' group separately, so it does not take into account if we chose parents to be before siblings or vice versa.

I'm OK with these changes even if they are not completely consistent with the configured rules, but I'm curious about the reasons of separating type imports from the other ones. Is there any standard import ordering convention leveraging that?

[TimoGlastra]

but anyway it is handling 'type' group separately, so it does not take into account if we chose parents to be before siblings or vice versa

Yeah this has been the case since we've started using type imports. Not sure why, but it's okay I think. I don't really mind the order, as long as it's consistent so we don't have merge conflicts based on it.

[TimoGlastra]

but I'm curious about the reasons of separating type imports from the other ones.

I kinda like it because it shows it's used as a type, and thus will be removed at compilation.

[morrieinmaas]

LGTM! massive PR @TimoGlastra. In general, reading through this I was wondering whether it'd make sense to use interfaces instead of abstract classes for base instances. Not 100% sure, but generally might be nice if the base class(es) never get(s) instantiated. Not part of this PR anyway but just as an idea. With interfaces we'd still get the typing right but without the impl (which saves some space by getting compiled away, given we don't need an impl of the abstract base itself, but just the implementations and extensions thereof).

[TimoGlastra]

Makes sense @morrieinmaas, thanks for the feedback. I've recently removed some abstract classes for interfaces and it felt a lot cleaner. Only place where it's useful is abstract classes that implement some functions, but we could also just extract them in util methods and implement twice 👍

Will keep in mind for future PRs