So you don’t like single line node modules. I don’t think I’ve ever used one. Maybe as a transient dependency, though.
But a function could be written in multiple ways, and I’m not sure we actually mean “single line” here. You’re referring to something of arbitrarily small complexity.
But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks.
Now, I’m sure I’ve leaned on these sorts of dependencies. Especially ones that have a peer dependency on a broken release, where they monkey-patch the problem. Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break.
> I don’t think I’ve ever used one. Maybe as a transient dependency, though.
The left-pad debacle proved that much of the ecosystem actually depends on such packages, at least indirectly.
> But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks.
I'm not sure what the point is here. Of course a huge module might only expose one public function. That's perfectly OK.
The context we were discussing was the question of whether an open-source project should be happy to accept a PR that only adds one (small) function to the project.
And the same question then extends to publishing that single small function as a separate module that others should add dependencies on, since that is essentially what TFA is arguing for.
But either way, the discussion was about modules that expose a small amount of (simple) functionality. And you're right, I'm saying "one line" as a proxy for that.
> Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break.
I don't understand this part at all.
Perhaps what wasn't clear was what "ideal" I am proposing instead. My ideal is having a dependency tree that is both small (few direct dependencies) and flat (my direct dependencies should also have a small and flat dependency tree of their own). That necessarily gravitates towards fat modules that include lots of functionality under the maintenance of a single team. Of course, this also presupposes a package manager and build system that can efficiently ignore parts of those modules that are not being used in a particular program.
So you don’t like single line node modules. I don’t think I’ve ever used one. Maybe as a transient dependency, though.
But a function could be written in multiple ways, and I’m not sure we actually mean “single line” here. You’re referring to something of arbitrarily small complexity.
But, getting back to the original comment, what’s to say that one exported function isn’t supported by 100 more non-exported functions? Or, worse case, a 1000 line function that could be decomposed into smaller blocks.
Now, I’m sure I’ve leaned on these sorts of dependencies. Especially ones that have a peer dependency on a broken release, where they monkey-patch the problem. Why would I invest in maintaining short lived code like that myself? My version manager would certainly tell me when things break.