191–197 of 197 posts
Earlier quoted context omitted.
Downvoters: I of course meant an authority on anything ELSE than memes and karmawhoring. Sorry for not being clear about that.
Okay. And you might say the failure is yours alone when you overeat, yet 30%+ of the USA is overweight. This little platitude only makes you feel better about yourself but isn't a good basis for designing something.
Earlier quoted context omitted.
NPM shouldn't scare you. Simple fact is you should not be relying on ANY package registry at the time of deployment.
> NPM shouldn't scare you. It absolutely should, just like any dependency on any other third party code or servers. Especially when they regularly have incidents like this. > Simple fact is you should not be relying on ANY package registry at the time of deployment. This is true, but doesn't prove the previous claim.
>> It absolutely should, just like any dependency on any other third party code or servers
There's no need to be scared of any of those things if you understand the trade-offs and risks.
>> Especially when they regularly have incidents like this.
They don't.
>> Simple fact is you should not be relying on ANY package registry at the time of deployment.
> This is true, but doesn't prove the previous claim.
The 'previous claim' follows from it. If you don't treat a package registry like an essential part of your own infrastructure, there's no need to be scared of it.
Earlier quoted context omitted.
> 1. As a developer I can not know with certainty that a package I publish will remain published under its current name. You can as long as your package name isn't trademarked or likely to confuse users installing the package. > 2. As a consumer of packages I can not trust that a library I am using won't get changed to a different piece of code due to someone else thinking they deserve the name better. I'm actually f…
Trademarks only apply within a common industry. Kik the company isn't in the business of creating NPM packages. It's perfectly legal to use the same name for something unrelated to messaging even after the founding date of the commercial entity.
Earlier quoted context omitted.
> and their behaviour up until now slightly suggests the opposite. Please elaborate. Afaik 'kik' wasn't significantly depended upon, and people using the old kik could still install it [1] (had the leftpad author not unpublished it), and that is the only example I'm aware of of npm handing over a package name. [1] http://blog.npmjs.org/post/141577284765/kik-left-pad-and-npm
Pretty sure "allover" isn't "significantly depended upon" - how would you feel if YC gave that account here to me just because I went and paid for a trademark on it?
And "significantly depended upon" doesn't make sense in your example, but is relevant in terms of a package in a registry.
Earlier quoted context omitted.
>Namespaced packages/repos have their own problems (figuring out which is the "good" one after some time and a few forks happen) Most if not all of these packages are hosted somewhere like Github. It's not hard to tell which repo has the most stars, fewest issues or most recent commit, that work's already done for you. But, we're talking about Node packages here - many of which seem to be trivial, or single line func…
> How many forks of left-pad could one expect to find? Javascript github repos: 70 of left-pad and 29 of leftpad. Some are jokes, but still... If you try the C++ package manager conan.io you will likely run into similar troubles. See for example https://github.com/lasote/conan-zlib/issues/23
Earlier quoted context omitted.
I agree in principal about not relying on npm during deployment. For a novice, what is the best way to ship modules?
My first thought was “What about including node_modules in your version control?” Downside is that the repo would be much larger, but if it’s going to expand to that size on the client after running “npm install”, maybe that’s not a big deal? But it feels kinda wrong to do that...