What if Kik uses Node and they broke their own builds inadvertently by enforcing their trademark. 0_0
I've Just Liberated My Modules
251–260 of 827 posts
Re: I've Just Liberated My Modules
#252Earlier quoted context omitted.
"echo" is not versioned and delivered on its own. It's part of gnu coreutils (which contains ~ 100 utilities), or part of various BSD core distributions (more than 100 utilities, plus the kernel and libc), and also built-in to shells.
IMO that doesn't change anything. The fact that in JS land it would be it's a standalone module means you get more choice in what you need (no need to pull down 100 programs if you only need 1 or 2).
You have the same amount of choice. There's no reason that you have to use the other hundred pieces of the package. In the Unix world, there's nothing precluding you from deciding to use the FreeBSD version of tar but keeping the rest of the GNU utilities there.
Re: I've Just Liberated My Modules
#253Why yes, depending on a third-party, external package manager is a huge risk. I have always believed that open source projects should be fully inclusive of any and all dependencies. This event has not changed that opinion.
Re: I've Just Liberated My Modules
#254Azer has contributed awesome modules to the community, but such a move _obviously_ messes with a bunch of people who previously didn't trust npm, but Azer. Npm works fine. There might be issues with it, but the reason builds are failing right now is that he decided to unpublish all of them - in a move that feels very kneejerky, despite him claiming that it's the opposite. If this had been actually in the interest of…
npm does not work fine if packages can be trivially removed (even by those who posted them), breaking everyone's builds.
Re: I've Just Liberated My Modules
#255Earlier quoted context omitted.
Yes you got it right. The third point was the special exception / grey area. For the record they made sure the exact same code was published to 0.0.3 so that I didn't maliciously inject anything. I control subsequent versions though.
Now that you own it what's to stop you from pushing out a new version with a slightly reworked string pad function under a commercial license (say a $100 per use fee)? Could make quite a pretty penny. Kind of crazy that this is possible at all.
Why on earth would someone pay for that if the code is already open source?
Re: I've Just Liberated My Modules
#256I applaud this action and while I'd like to point the finger at NPM, there's no real other method to fix historical package versions that depend on this. It is worth pointing to the silly state of NPM packages: Who decided that an external dependency was necessary for a module that is 17 lines of code? module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch =…
https://en.wikipedia.org/wiki/Unix_philosophy
Let it suffice to say that Linux distributions (and some closed OSes) try very hard to prevent package fragmentation.
Experience has shown many times that excessive fragmentation leads to proliferation of unmaintained libraries.
Re: I've Just Liberated My Modules
#257Earlier quoted context omitted.
I'm not saying that everything should be a module, but that well designed, well tested bits of code should be modules. These 17 lines had 100% test coverage and were used by a stupidly large amount of people (read: battle tested), why not use it? As is pointed out elsewhere in this thread, echo.c is roughly the same size, does that mean it's not a worthy program?
Realistically 17 lines of code is total overkill for this function. In many cases you could achieve the same thing more efficiently in a single line.
Feel free to show a smaller implementation that's more efficient.
I've seen several "one liners" in this thread already, and most of them either blow up when something that's not a string is passed in (regardless of how you view strict typing, js doesn't have it and this shouldn't happen), or are extremely slow comparatively (most of them creating and destroying an array every time they are called).
Plus this has 100% test coverage (even as trivial as it is, it still counts), and is "battle tested" (something like 2.5 million installs per month counts for something).
Sorry, but i'll stick to left-pad vs 20-seconds of thought one-liner.
Re: I've Just Liberated My Modules
#258Earlier quoted context omitted.
My point is mostly that often, when it comes to law, lay-people talk about what they _wish_ the law was, rather than what the law actually is. And yeah, lawyers can be wrong too. But sometimes, things that seem common-sense aren't actually legally correct, and this is one of those cases. It does feel silly that a messaging company can threaten to sue over an unrelated software package, but that's just part of how int…
> My point is mostly that often, when it comes to law, lay-people talk about what they _wish_ the law was, rather than what the law actually is. That is why the law should be formalized such that correctness proofs for argumentations can be given and in doubt even be checked independently by a computer. Exactly because of the possibility of different opinions and wishes, coming up with such a high standard should be…
While I can appreciate this sentiment, I'm also not sure that removing any sort of interpretation is a good idea. Look at the horrible impact mandatory minimum sentencing has had, for example. Flexibility can be bad, but it can also be very good.
Re: I've Just Liberated My Modules
#259Earlier quoted context omitted.
Ahh you are right, all makes sense now, thanks!
You need to go something like: module.exports = function leftpad (str, len, ch) { return Array(Math.max(0, len - String(str).length)).join(ch || ' ') + String(str); }; Unfortunately we need to wrap str twice so maybe a one-liner is not quite in place.
Also, this doesn't support zero padding with ch=0.
Re: I've Just Liberated My Modules
#260I applaud this action and while I'd like to point the finger at NPM, there's no real other method to fix historical package versions that depend on this. It is worth pointing to the silly state of NPM packages: Who decided that an external dependency was necessary for a module that is 17 lines of code? module.exports = leftpad; function leftpad (str, len, ch) { str = String(str); var i = -1; if (!ch && ch !== 0) ch =…
Personally i'm going to use an installable module for something even that small, because i can, and it works. The benefits from an install registry don't go away just because the module is very tiny... Why would i spend my time re-inventing the wheel for every little thing i do? And if i'm not reinventing, then i'd be copy/pasting which is much worse. At best that's a waste of time and effort to properly document the…
The overhead is in your management of your dependencies. The size of the module isn't the problem, it's the fact that you end up using so many of them (especially recursively).
Consider this specific case. This author moved all their modules from one hosted location to another. Now, if you want to use these modules from that author, you need to update the scripts and configs that install them (some package.json files in this case). In a better world, like the C or Python world, you might need to update one or two urls which point to a couple of this author's popular libraries (maybe one you use directly, and one used by one of your handful of direct dependencies).
In this crazy npm world, this author has 272 modules. Maybe 20 are in widespread use ... it's already a lot of work to figure that out. Maybe you use a couple directly, and your dependencies have private recursive sub-dependencies on additional copies or versions of these or other of this author's modules! Maybe you have to cut your own versions of some of your dependencies just to change their package.json to refer to the new URLs! Anyway, you probably have to sift through hundreds of your dependencies and sub-dependencies to see if any of them are included in these 272 moved modules.
I've seen npm dependency trees with over 2000 modules (not all unique of course). That's totally unmanageable. I think that's why privately versioned sub-dependencies is a big feature in nodejs: so you can try to ignore the problem of an unmanageable dependency tree. But if you need to make reliable software, at some point you need to manage your dependencies.