Let give some background for myself to help you get context. I've developed as hobby before internet and then I did .NET C# for a long time sometime until 2010. I was mostly involved with enterprise software.
Personally, I would feel ashamed to publish such a package. It feels incomplete and even I started this with bigger dreams, most probably it will never receive a 1.0 version. I would rather gist/block my amazing code for inspiration rather than doing this. I'm writing this to help you connect with the perspectieve that is driven from my background. I hope this help you give context for the following.
The concept of package repositories is amazing. But, for my background, to add a package dependency, the package needs to offer something substantial. I don't think that there is any gain here when 10line code packages that don't even have a major verion are linked everywhere. It is a very volatile situation.
When a package is delivered as binary, then a small referenced package is of a lesser problem because the deliverable includes the compiled code. For example in .NET, the only potential problem is that if 2 different packages have the same dependency then 2 dlls with the same name lead to problems at runtime. But, outside of the compiled world, there is the concept of builing everything which multiplies the potential problems of this approach. Because, if my package needs to be built, then my dependency and its dependencies need to be built as well. Everytime I try to work with node and use a tool, it's like it never works out of the box. Errors and warning over wring 0.0 packages etc. If you think about it, easy workaround suggested everywhere is to override the version restrictions like bundle exe. It makes you wonder what is the point? Yes, the desciplined shops will not do this, but from all my circle, developer and especially junior ones are more and more copy/pasting from a proposed solution and if it works, then its in without evaluation. Yes there are code reviews etc but lets be honest here about how effective these are when the code is not evaluated by the whole planet. :)
Call me concervative but when a package is small, I prefer the copy of it's code in a designated location with a clear mention for future maintanence but there is control. I'm glad that there is open source and I can get insight and inspiration but adding non major dependencies is already a problem in my approach, yet alone when the dependency is 10 lines. It's not worthwhile. I can always revisit this and chose the code when it is mature. But this is a nice plan that goes all to the garbage when a nice big package has dependencies to 10line of code non major versioned releases.
I believe that the current mess (not only in javascript) with non major packages is because of what I mention in the top of me being ashamed to publish a 10line package. I'm sure I'm not the only person who has this mental blocker but still wants to share. Like "viral" the outcome of the usage could be very far from my original expectations and planning.
IMO it's not a matter of how many lines of code the package is, but a matter of how well tested it's in the CI pipelines. When you see in the repo that the authors have added tests that make you happy, you may use it. If the only tests are a linter then it's time to look for a different package. The power of open source is that in fact, you can see these things and not put your trust in some entity.
But the situation in the original anecdote completely bypasses any question of testing. Because you can test a package all day long, but the core question is: What do you do if that package... disappears???
That is also part of my point. Every package is a dependency and a potential problem. You need to weight the benefits against the risks.
If for every package you need to check quality, license and lifetime then maybe the overhead is to big. If the organisation has actual oss policies, then it can get out of control. What if the package changes license?
There is a reason that in ESCROW agreement, all dependencies are included.
Let give some background for myself to help you get context. I've developed as hobby before internet and then I did .NET C# for a long time sometime until 2010. I was mostly involved with enterprise software.
Personally, I would feel ashamed to publish such a package. It feels incomplete and even I started this with bigger dreams, most probably it will never receive a 1.0 version. I would rather gist/block my amazing code for inspiration rather than doing this. I'm writing this to help you connect with the perspectieve that is driven from my background. I hope this help you give context for the following.
The concept of package repositories is amazing. But, for my background, to add a package dependency, the package needs to offer something substantial. I don't think that there is any gain here when 10line code packages that don't even have a major verion are linked everywhere. It is a very volatile situation.
When a package is delivered as binary, then a small referenced package is of a lesser problem because the deliverable includes the compiled code. For example in .NET, the only potential problem is that if 2 different packages have the same dependency then 2 dlls with the same name lead to problems at runtime. But, outside of the compiled world, there is the concept of builing everything which multiplies the potential problems of this approach. Because, if my package needs to be built, then my dependency and its dependencies need to be built as well. Everytime I try to work with node and use a tool, it's like it never works out of the box. Errors and warning over wring 0.0 packages etc. If you think about it, easy workaround suggested everywhere is to override the version restrictions like
bundle exe. It makes you wonder what is the point? Yes, the desciplined shops will not do this, but from all my circle, developer and especially junior ones are more and more copy/pasting from a proposed solution and if it works, then its in without evaluation. Yes there are code reviews etc but lets be honest here about how effective these are when the code is not evaluated by the whole planet. :)Call me concervative but when a package is small, I prefer the copy of it's code in a designated location with a clear mention for future maintanence but there is control. I'm glad that there is open source and I can get insight and inspiration but adding non major dependencies is already a problem in my approach, yet alone when the dependency is 10 lines. It's not worthwhile. I can always revisit this and chose the code when it is mature. But this is a nice plan that goes all to the garbage when a nice big package has dependencies to 10line of code non major versioned releases.
I believe that the current mess (not only in javascript) with non major packages is because of what I mention in the top of me being ashamed to publish a 10line package. I'm sure I'm not the only person who has this mental blocker but still wants to share. Like "viral" the outcome of the usage could be very far from my original expectations and planning.
IMO it's not a matter of how many lines of code the package is, but a matter of how well tested it's in the CI pipelines. When you see in the repo that the authors have added tests that make you happy, you may use it. If the only tests are a linter then it's time to look for a different package. The power of open source is that in fact, you can see these things and not put your trust in some entity.
But the situation in the original anecdote completely bypasses any question of testing. Because you can test a package all day long, but the core question is: What do you do if that package... disappears???
That is also part of my point. Every package is a dependency and a potential problem. You need to weight the benefits against the risks.
If for every package you need to check quality, license and lifetime then maybe the overhead is to big. If the organisation has actual oss policies, then it can get out of control. What if the package changes license?
There is a reason that in ESCROW agreement, all dependencies are included.
Agreed. This is also why many companies have started using solutions like Artifactory.