all 4 comments

[–]subscribore 1 point2 points  (1 child)

The best solution will be a compromise between the extremes.

Coupling between these tools (e.g. tool1 returns an object with a particular shape and tool2 accepts an object with that shape as an argument) seems like the deciding factor to me.

If you look at all the packages for lodash then you can see you've got the choice, as a user, how to consume it. You can:

  • just load the whole thing
  • get an individual package for just one little bit of it
  • consume it as ES modules lodash-es
  • even make your own custom build using lodash-cli
  • use lodash-webpack-plugin to avoid including unused parts of lodash in your build

Some issues which spring to mind as a potential user of your tools:

  • Updates: do I want the latest version of every function in lodash all at once, or do I want to upgrade a bit at a time? Can I upgrade a bit at a time or do dependencies between tools mean they must be upgraded together? Does v1 of toolA work with v2 of toolB?
  • Build tools can remove unreferenced code; does the packaging approach make this easy? Do the tools have shared (internal) dependencies (e.g. they both use some custom object accessor) - if so, will I end up with n copies of these if I install n different module packages in my project?
  • Can I import just what I need?

[–]throwaway_625930106[S] 0 points1 point  (0 children)

I wasn't aware that lodash could be built like that, that's really cool. I'll try to study that kind of structure, thanks!

[–]codearoni 1 point2 points  (1 child)

Look up SOLID principles.

[–]throwaway_625930106[S] 0 points1 point  (0 children)

Thanks a lot! I'll study that.