5 ms·

> contribution to open source can be as simple as contributing a single function Are there meaningful contributions to open source that are the size of a singl

> contribution to open source can be as simple as contributing a single function Are there meaningful contributions to open source that are the size of a single function? Isn't this what leads to the terrible failure modes of NPM (hello left-pad)? If you want to contribute a single function, what's wrong with a blog post? Also, has the browser not solved this with ESM imports from URLs? I can write a web page containing import {someFunction} from "https://your-website.com/your-script.js"; This also solves the namespacing issues - at least to the extent that the domain name system solves namespacing issues. (Deno, of course, inherits this ability to import code from any URL.) I'm being provocative. I've heard people make similar arguments over time, but never understood why anyone would want open source contributions to be a single function.

dfee 3y ago
What’s wrong with a function? Here’s an interesting discussion on the topic, btw: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus/ama/issues/10
- tsimionescu 3y ago
  Code is much harder to maintain than it is to create, overall. Adding lines of code to a project is a net negative in the long run if they are not actively maintained by the original author. So as a project maintainer, you don't really want lots of small contributions from random people who don't stick around, at least not when they are adding new behavior to your project. And having thousands of one-line dependencies is actually much worse than having one thousand-lines dependency, since you now depend on the whims of each of those creators not to stop distributing their work, not to change their license, not to inject malicious code, to address zero-days etc.. Ultimately external dependencies are a form of collaboration, and it's very hard work to efficiently collaborate with thousands of people.
  - dfee 3y ago
    Ok. 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.
    - tsimionescu 3y ago
      > 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.
  - vineyardmike 3y ago
    Counter argument: 1000 one-liners may each need less maintenance. And bugs are more self contained. The example in the article is the Fibonacci algorithm and general helper methods. A “remove whitespace” method could easily be set and forgotten (esp with testing). A 1000 line library probably needs maintenance because there is more moving parts and if there’s a bug, you’ll have to test/update a lot more things. I think the solution to the problems raised are not small libraries but a large standard library with good composable tools. I don’t know the specifics of erlang but in many programming languages things like remove a string whitespace is easy to do inline with the STDLIB instead of downloading a helper method, either in a bigger context or alone.
- deleted 3y ago
  [deleted]
- crabmusket 3y ago
  I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~= small NPM packages. That's where his argument fails, IMO. Let's assume the alternative to "small NPM packages" is not "large NPM packages", but "small modules, vendored into my own repository". In this comparison, the benefits of small NPM packages become: - Transient dependencies are automatically managed for you - You can pull updates from the repository to get new features and bug fixes, and when you do this, as above, changes in transient dependencies are automatically managed for you - The package gets a vanity download count on npmjs.com There are meaningful tradeoffs here, but they're different to trying to rehash the benefits of modular code. Of course modular code is good. But packaging and distributing code is a whole different story. EDIT: I'm having a bit of a reaction against the excesses of the NPM ecosystem at the moment. As, I think, are a lot of developers. I hope the pendulum swings from its current state more towards "fewer, better dependencies". Not towards "dependencies the size of a single function".
  - crabmusket 3y ago
    Darn it, s/transient/transitive
iainmerrick 3y ago
Absolutely! Here’s one I found very useful just the other day, client-zip: https://github.com/Touffy/client-zip#usage https://github.com/Touffy/client-zip#usage (Three functions rather than one, but it’s one main entrypoint and a couple of minor variants.) I think this is a really well-designed API, and greatly preferable to a more fine-grained OO approach. It does a lot of work under the hood but keeps it carefully contained so you don’t get a bunch of dependency sprawl.
- crabmusket 3y ago
  The API may be a single function, but that package contains a non-trivial amount of code. The contribution this package makes to your codebase is not "a single function". However, at a glance, I agree with your reasons for liking it! And I'd be unlikely to vendor it directly into an app or dependent library for example. EDIT: it feels to me like the CRC32 implementation contained in that library is a prime example of what the original article had in mind. There should be one global CRC32 function which every person could pull and reuse, instead of bundling it with their own package!
vvvvtt340 3y ago
One example I can think of is the "immer" package / the "produce" function: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/ https://immerjs.github.io/immer/api https://immerjs.github.io/immer/api The API page lists numerous functions, but the bottom of the page says "In most cases, the only thing you need to import from Immer is produce". My thought is, immer does something novel, but the vast majority of functionality can be covered in one function. I think another problem with the "left-pad" situation is the lacking "JavaScript standard library", but that situation is improving over time, especially now that IE11 is deprecated so it's a reasonable expectation to develop against Chrome / Firefox / Safari which are actively maintained and continue to implement new JavaScript features.

dfee 3y ago

What’s wrong with a function? Here’s an interesting discussion on the topic, btw: https://github.com/sindresorhus/ama/issues/10 https://github.com/sindresorhus/ama/issues/10

tsimionescu 3y ago
Code is much harder to maintain than it is to create, overall. Adding lines of code to a project is a net negative in the long run if they are not actively maintained by the original author. So as a project maintainer, you don't really want lots of small contributions from random people who don't stick around, at least not when they are adding new behavior to your project. And having thousands of one-line dependencies is actually much worse than having one thousand-lines dependency, since you now depend on the whims of each of those creators not to stop distributing their work, not to change their license, not to inject malicious code, to address zero-days etc.. Ultimately external dependencies are a form of collaboration, and it's very hard work to efficiently collaborate with thousands of people.
- dfee 3y ago
  Ok. 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.
  - tsimionescu 3y ago
    > 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.
- vineyardmike 3y ago
  Counter argument: 1000 one-liners may each need less maintenance. And bugs are more self contained. The example in the article is the Fibonacci algorithm and general helper methods. A “remove whitespace” method could easily be set and forgotten (esp with testing). A 1000 line library probably needs maintenance because there is more moving parts and if there’s a bug, you’ll have to test/update a lot more things. I think the solution to the problems raised are not small libraries but a large standard library with good composable tools. I don’t know the specifics of erlang but in many programming languages things like remove a string whitespace is easy to do inline with the STDLIB instead of downloading a helper method, either in a bigger context or alone.
deleted 3y ago
[deleted]
crabmusket 3y ago
I'm very familiar with that specific discussion. I find Sindre's arguments very convincing in regard to small modules. But he then assumes that small modules ~= small NPM packages. That's where his argument fails, IMO. Let's assume the alternative to "small NPM packages" is not "large NPM packages", but "small modules, vendored into my own repository". In this comparison, the benefits of small NPM packages become: - Transient dependencies are automatically managed for you - You can pull updates from the repository to get new features and bug fixes, and when you do this, as above, changes in transient dependencies are automatically managed for you - The package gets a vanity download count on npmjs.com There are meaningful tradeoffs here, but they're different to trying to rehash the benefits of modular code. Of course modular code is good. But packaging and distributing code is a whole different story. EDIT: I'm having a bit of a reaction against the excesses of the NPM ecosystem at the moment. As, I think, are a lot of developers. I hope the pendulum swings from its current state more towards "fewer, better dependencies". Not towards "dependencies the size of a single function".
- crabmusket 3y ago
  Darn it, s/transient/transitive

iainmerrick 3y ago

Absolutely! Here’s one I found very useful just the other day, client-zip: https://github.com/Touffy/client-zip#usage https://github.com/Touffy/client-zip#usage (Three functions rather than one, but it’s one main entrypoint and a couple of minor variants.) I think this is a really well-designed API, and greatly preferable to a more fine-grained OO approach. It does a lot of work under the hood but keeps it carefully contained so you don’t get a bunch of dependency sprawl.

crabmusket 3y ago
The API may be a single function, but that package contains a non-trivial amount of code. The contribution this package makes to your codebase is not "a single function". However, at a glance, I agree with your reasons for liking it! And I'd be unlikely to vendor it directly into an app or dependent library for example. EDIT: it feels to me like the CRC32 implementation contained in that library is a prime example of what the original article had in mind. There should be one global CRC32 function which every person could pull and reuse, instead of bundling it with their own package!

vvvvtt340 3y ago

One example I can think of is the "immer" package / the "produce" function: https://immerjs.github.io/immer/ https://immerjs.github.io/immer/ https://immerjs.github.io/immer/api https://immerjs.github.io/immer/api The API page lists numerous functions, but the bottom of the page says "In most cases, the only thing you need to import from Immer is produce". My thought is, immer does something novel, but the vast majority of functionality can be covered in one function. I think another problem with the "left-pad" situation is the lacking "JavaScript standard library", but that situation is improving over time, especially now that IE11 is deprecated so it's a reasonable expectation to develop against Chrome / Firefox / Safari which are actively maintained and continue to implement new JavaScript features.