Migrate hawtio-kubernetes-api to react (and remove angular dependency)

[phantomjinx]

• Ensure each sub-module contains a tsup.config.ts config file, thereby mandating a uniform standard of output naming. Define entry, and specify it as src/index.ts;

• Every module should provide index.ts as its entrypoint. Then the main and types properties in the package.json will always be standardized;

• Ensure correct module federation by adding @hawtio/react as a singleton in the webpack build configuration. This may well alleviate issues with js-logging not being defined;

• Nest workspaces are still under investigation as valid configuration for yarn v2+ (see this). So avoid them for the moment. Any test apps should be hoisted to top level;

• package.json dependencies / devDependencies are quite old everywhere. Need to upgrade them and remove unnecessary ones to keep up with hawtio-next;

• File naming for independent plugin: not necessary to add plugin prefix to each file, as the plugin package should be independent with no concerns to taint global namespace;

• eventemitter.d.ts is not required. The d.ts should be provided already from the lib;

• urljs should be replaced. The project itself states, there's no reason to use this lib anymore;

• Investigate extensions of the hawtio-next eventService to make it available for hawtio-k8s-api.

[tadayosi]

Just FYI, I had investigated at #67 whether we could move from our own hawtio-k8s-api to some more official like https://github.com/kubernetes-client/javascript, but it turned out it's only for server-side (Node):

• browser-side support kubernetes-client/javascript#165

So we are sure we need to keep it and refresh it to React for hawtio-online v2.

[phantomjinx]

What about this one -> https://github.com/godaddy/kubernetes-client ??

Seems to have an API and backends.

[phantomjinx]

Consider using nock as a testing mock for a kubernetes cluster to return an API used by client. See example here.

[tadayosi]

What about this one -> https://github.com/godaddy/kubernetes-client ??

When we consider 3rd party libs to substitute from our own impl, we should take sustainability into account, as we receive many security issues on a variety of components. If a 3rd party lib we use is abandoned, we'd need to end up patching it or rewrite it ourselves.

I'm concerned that this project hasn't been updated for 3 years. I think this time it's most straightforward to keep our own module and migrate hawtio-k8s-api to React or framework-free. Looking at the core part, it doesn't seem to depend so much on AngularJS. Simply removing the AngularJS API from the code doesn't seem to be so difficult.
https://github.com/hawtio/hawtio-kubernetes-api/blob/main/plugins/kubernetes-api/client.ts

[tadayosi]

Consider using nock as a testing mock for a kubernetes cluster to return an API used by client. See example here.

On the other hand, we can consider using testing frameworks like this more easily as they should be dev only dependents and we can normally take security issues from those testing tools as moderate.

[phantomjinx]

Migrated to 2.x branch and then to be main