Utility methods, when is a util method warranted? about pnp-js-core

[alex-randall]

Wondering if we should not expose these util methods outside the library publically (and just use them internally) since there might be some overlap with other libraries out there.

Or... maybe a select few functions in it should be public?

[pbjorklund]

I like having some of them exposed for doing things that are clunky. However I think they should be exposed via their own classes instead of through a 'Util' class (most obvious crime against separation of concerns)

[patrick-rodgers]

Where possible I want to avoid referencing other libraries since it would force a consumer to also include that lib to use ours. The dateAdd is there because I needed something for the cache expire stuff. I don't really want to handle dates universally. IsFunction is similar, we need that test and it takes up three lines, so I prefer not to take a dep to get three lines of code. Some of the other util methods are there because they are things I have used regularly in the past and were part of the js core from which this was derived. getRansomString forex I often use when creating dynamic DOM elements that need an ID. Always want to keep the conversation going on what makes sense vs. what doesn't, but I am OK with what we have currently.

We do currently expose them through pnp.util on the root object which simulates a class to the consumer.

[patrick-rodgers]

Going to close this issue - I think we are in agreement that we need to limit the utility code we write, while keeping a focus on not taking dependencies for a few lines of code in some other library. In other words I think take what we absolutely need to make our library work. Then folks can use whatever they want outside that in their projects.