A one-line package broke `npm create-react-app` • Hacker News Board

Re: A one-line package broke `npm create-react-app`

#181

Post by gpm » Sat, Apr 25, 2020, 7:07 PM UTC

throwanem wrote: post #169

gpm wrote: post #163

Earlier quoted context omitted.

The language has nothing to do with it. The point is just that the name "then" is a perfectly common method name. If a small standard library is using it for things that aren't promises, you can bet your ass that there are javascript libraries using it for things that aren't promises. Like I said, I just chose to look at rust first because it's documentation has a good search bar.

The language has everything to do with it, because the language is the locus of practice. Rust practice is whatever it is, and is apparently pretty free with the use of "then" as a method name, which is fine. Javascript practice isn't the same as Rust practice, and Javascript practice includes a pretty strong norm around methods named "then". That's why the next time I run into such a method, that doesn't belong to a…

It doesn't call into question the idioms of either language. It does call into question the idea of programmatically deciding whether or not something is a promise based on the assumption that the idiom was followed.

People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, not only an avenue for malicious code to cause trouble.

Re: A one-line package broke `npm create-react-app`

#182

Post by enitihas » Sat, Apr 25, 2020, 7:08 PM UTC

0xff00ffee wrote: post #174

enitihas wrote: post #95

Earlier quoted context omitted.

You don't need so many dependencies with python. Python is a batteries included language, and so are most python libraries.

I fully disagree. Open up any serious Python project and you'll find significant dependencies. Math, graphics, IO, stats, ML... anything you really want to do requires dependencies. In fact, one of my biggest issues with Python is the cross-platform incompatibility of many packages which makes it a terrible choice for my deployment. (Even worse if the project has Cython components!) I often end up having to scour git…

Math -> You use numpy, scipy, none of these have any significant dependencies. And libraries this complex are not even available for node.

Graphics -> Python comes with included Tkinter, and others are also one include away.

Stats -> Scipy does a lot of the stuff. There is a built in package for stats. Again, no stats package has 100 dependencies, and node doesn't even have anything with even 1/10th of the features

ML -> I mean node has nothing here, nothing, while pytorch has total of six dependencies. In node, left pad might have these many.

Python doesn't need left pad, isNumber, isInteger, isOdd, isPromise , take your pic.

> In fact, one of my biggest issues with Python is the cross-platform incompatibility of many packages which makes it a terrible choice for my deployment. (Even worse if the project has Cython components!)

But python has high performance libraries written in C, can you even use node for any of the cases where python has platform compat issues?

It is a tradeoff, and there is no comparison. Python needs far far less dependencies than node. e.g, Flask has 2 total dependencies, express has 48 direct dependencies, and even then flask comes out ahead on features, so much so that you would need many more packages to do the same stuff with express.

Re: A one-line package broke `npm create-react-app`

#183

Post by bdcravens » Sat, Apr 25, 2020, 7:09 PM UTC

btilly wrote: post #119

montroser wrote: post #43

Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production. This was an honest oversight, and even somewhat inevitable with so many expected supported ways to import/export between cjs mjs amd umd etc. It will happen again. And when it happens the next time, if it ruins your life again, take issue with yourself for not…

And everyone who depends on projects that pin their dependency versions gets to be victims of security exploits long after they are fixed. Dependency management is not as simple as you seem to think.

The unspoken assumption is that you don't just pin and move on with your life. You take as much ownership over your package.json as you do with your own code, and know that you must actively review and upgrade as necessary (as opposed to just running "npm install" and trusting in the wisdom of the cloud)

Re: A one-line package broke `npm create-react-app`

#184

Post by __s » Sat, Apr 25, 2020, 7:10 PM UTC

alerighi wrote: post #130

staticassertion wrote: post #45

Earlier quoted context omitted.

Here's my off-the-cuff take that will not be popular. A function like this should be a package . Or, really, part of standard js, maybe. A) The problem it solves is real. It's dumb, but JS has tons of dumb stuff, so that changes nothing. Sometimes you want to know "is this thing a promise", and that's not trivial (for reasons). B) The problem it solves is not straightforward. If you Google around you'll get people sa…

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…

TypeScript supports 'function f(x: any): x is T' as a way to declare that if f returns true, x may pass as type T

https://www.typescriptlang.org/docs/handbook/advanced-types....

Re: A one-line package broke `npm create-react-app`

#185

Post by andrewzah » Sat, Apr 25, 2020, 7:11 PM UTC

sergiotapia wrote: post #172

steveklabnik wrote: post #110

Earlier quoted context omitted.

I have posted one liners to crates.io that were eventually put in the stdlib.

True this problem also exists in Rust, even going so far as people "claiming" and SELLING nice package names.

Name squatting on crates.io is another issue entirely, though. It's also a can of worms that I won't open.

Re: A one-line package broke `npm create-react-app`

#186

Post by zulgan » Sat, Apr 25, 2020, 7:12 PM UTC

ddevault wrote: post #66

zulgan wrote: post #42

Chill with the js hate, this happens everywhere. Maybe not to this extend, but if X (where X is whatever you are thinking about) had similar amount of people using it (especially junior people) this would happen there as well.

No, this does not happen everywhere. Show me this happening in Debian.

haha i understand what you mean, but debian's https://wiki.debian.org/DontBreakDebian page is not an accident :)

i made my comment more as a joke, shit happens everywhere, and as i said maybe not to this extend.

Re: A one-line package broke `npm create-react-app`

#187

Post by wildpeaks » Sat, Apr 25, 2020, 7:15 PM UTC

montroser wrote: post #43

Everyone crying about this on the Internet would do better to just take it as an easy lesson: pin your dependency versions for projects running in production. This was an honest oversight, and even somewhat inevitable with so many expected supported ways to import/export between cjs mjs amd umd etc. It will happen again. And when it happens the next time, if it ruins your life again, take issue with yourself for not…

Exactly: pin dependencies to avoid surprises, and use a CI to test compatibility of new versions, so you can deploy security updates on your own schedule, best of both worlds.

Github even bought Dependabot last year, so it's now free.

Re: A one-line package broke `npm create-react-app`

#188

Post by bdcravens » Sat, Apr 25, 2020, 7:15 PM UTC

rubyn00bie wrote: post #144

Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah,…

create-react-app contains over 1000 packages. How long would it take to review all of those?

Re: A one-line package broke `npm create-react-app`

#189

Post by fludlight » Sat, Apr 25, 2020, 7:19 PM UTC

aylmao wrote: post #157

jackewiehose wrote: post #49

I think these one-line-packages aren't the right way to go. Either JS-developers should skip the package-system in that case and just copy and paste those functions into their own project or there should be more common used packages that bundle these one-liners. I mean is_promise() and left_pad() are not worth their own package. Packages-dependencies of 10000 packages for trivial programs are just insane. Is someone…

I see a lot of criticism to one-line packages, but IMO in the end what matters is the abstraction. Thinking of the package as a black box, if the implementation for left-pad or is-promise was 200 lines would it suddenly be ok for so many other packages to depend on it? Why? The size of the package doesn't make it less bug-prone. I see plenty of people who are over-eager to always be up-to-date, when there really isn'…

It would be more ok if left-pad was part of a package called, say, text-utils which also included right-pad, etc. Same with is-promise, it sounds like it should be a function in a package called type-checker.

Re: A one-line package broke `npm create-react-app`

#190

Post by monkpit » Sat, Apr 25, 2020, 7:19 PM UTC

gpm wrote: post #137

throwanem wrote: post #99

Earlier quoted context omitted.

I mean, if you have to assume deliberately adversarial action on the part of your own codebase, you may have worse problems than having to duck-type promises.

A class with a `then` method isn't a rare thing that could only come up adversarially. Below I've linked two example from the rust std-library (I just chose that language because the documentation is really easy to search for objects which have a method name then). I think we can be sure that both booleans, and the "less than, equal to, or greater than" enum are not in fact promises. https://doc.rust-lang.org/std/pri…

Cypress.io has chainable .then functions but they are not await-able and the documentation clearly states they are not promises and cannot be treated as such. It’s a bad idea, but it is out there.