chore: Exports utils directory for consumption by hawtio-online

[phantomjinx]

• Utilities that were originally provided by hawtio-core are still required in hawtio-online so need to be exported

[tadayosi]

I wouldn't expose all functions from util. Exposing functions and types from index.ts means exposing them as the API hawtio-next provides. I don't think tiny util functions like isString are something hawtio-next should provide as API. As far as I can see so far, probably only functions from jolokia.ts can be justifiable as part of hawtio-next's API.

Also, deciding to keep all such common utils across the hawtio-related components in hawtio-next would make those components unnecessarily tightly-coupled with each other. For example, if we want to change some util function from hawtio-next at hawtio-online, it would require to patch hawtio-next and wait for a next release of the package to finally consume the change at hawtio-online. It's unnecessarily long distance for generic util functions.

So what should we do instead? If we were careless about security issues we would have used common util packages such as lodash. So, for generic util functions which are substitutable with lodash, we can instead just duplicate the same functions at hawtio-online and maintain them in their own project.

I'd like to know what list of util functions from hawtio-next hawtio-online is currently required to depend on? So that we can further examine which utils should be really exposed and which should be just duplicated.

[tadayosi]

As far as I can see so far, probably only functions from jolokia.ts can be justifiable as part of hawtio-next's API.

Talking a bit further about jolokia.ts, for even this file, probably hawtio-next is not the best place to put them for shared usages. Maybe we should move them to jolokia.js project as companion helper functions for the official jolokia.js, so that both hawtio-next and hawtio-online (and possibly even other projects such as artemis-self-provisioning-plugin) can share them.

[phantomjinx]

I wouldn't expose all functions from util. Exposing functions and types from index.ts means exposing them as the API hawtio-next provides. I don't think tiny util functions like isString are something hawtio-next should provide as API. As far as I can see so far, probably only functions from jolokia.ts can be justifiable as part of hawtio-next's API.

Also, deciding to keep all such common utils across the hawtio-related components in hawtio-next would make those components unnecessarily tightly-coupled with each other. For example, if we want to change some util function from hawtio-next at hawtio-online, it would require to patch hawtio-next and wait for a next release of the package to finally consume the change at hawtio-online. It's unnecessarily long distance for generic util functions.

So what should we do instead? If we were careless about security issues we would have used common util packages such as lodash. So, for generic util functions which are substitutable with lodash, we can instead just duplicate the same functions at hawtio-online and maintain them in their own project.

I'd like to know what list of util functions from hawtio-next hawtio-online is currently required to depend on? So that we can further examine which utils should be really exposed and which should be just duplicated.

I'd agree. Duplication is the only thing stopping me from re-adding them to hawtio-online. Here is the list:

• joinPaths (url package)
• isString (string package)
• isObject (object package)
• isArray (object package)

So if you're good with duplicating them then I'll close this PR. Does help me since I don't have to keep publishing hawtio-next locally.

[tadayosi]

They are small enough to be duplicated at hawtio-online. Please go ahead.

[tadayosi]

Closing as discussed.