Consider removing lodash-es usage

[solkaz]

I wanted to ask if there was a specific reason to use lodash-es in the project? It uses the following utilities (search result), which either have native equivalents, or easy replacements:

• each (actually forEach) - Array#forEach can be used
• filter - Array#filter can be used
• find - Array#find can be used
• some - Array#some can be used
• isEmpty - no native method, but where being used, simple falsy checks might be good enough
  • Usage 1 - seems to be checking if a string is empty
  • Usage 2 - checking result of Storage.getItem, which will either be a string or null

[SDohle]

Hi, we created this module to consume it in a project which is using lodash. There is no other technical reason. Feel free to provide a pull request because I'm not sure if some of our developers will find time for that refactoring.

[miller45]

loadash-es supports tree-shaking without webpack 4. So the impact should be minimal because only the functions we use. The reason we using them is basically that at the time the code was initially written our typescript version did not support the ? operator, so back then it would be always if( value != null || value.length == 0) and today webstorm would mark that as code duplicate if we use that a lot...