Live data from Hacker News

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

github.com

141–150 of 478 posts

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

#141
post #106

Earlier quoted context omitted.

Know what happens every time people like you say this here on HN? They post the one-liner they would have manually implemented in their code base and it's wrong . The one that comes to mind is the "is-negative-number" package. Yes, the geniuses of Hacker News, after finding out there was an npm package for determining whether something was a negative number, could not correctly implement that function. You and everyo…

Maybe its a failure of the language when it takes a third party package to determine if a number is greater than or less than zero?

> Maybe its a failure of the language when it takes a third party package to determine if a number is greater than or less than zero?

It's not a failure of the language. Javascript has comparison operators like every other language, it's entirely possible to determine if a number is greater than or less than zero without importing a third-party package.

What it is is a failure of modern JS development culture, because apparently it's anathema to even write a simple expression on your own rather than import a dependency tree of arbitrary depth and complexity and call a function that does the same thing.

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

#142

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…

I'm a novice in this area but if your project relies on a bunch of external node packages why wouldn't you download them all and host them locally or add them to version control?

Adding them to your own version control is a nightmare: Your own work will drown in all the changes in your dependencies. The repository will quickly grow to gigabytes, and any operation that would usually take seconds will take minutes.

It's also just not needed. Simply specifying an exact version ("=2.5.2") will avoid this problem. The code for a version specified in this manner does not change.

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

#143
post #122

Earlier quoted context omitted.

package.json only lists top-level dependencies. package-lock.json tracks all dependencies, and dependencies of dependencies. is-promise is one of those dependencies of a dependency, which you don't have much control over.

How could a dependency-of-dependency change version if one of the direct dependencies doesn't change version? I guess, if the direct dependency isn't pinning that version? Another case of, everyone should be pinning dependencies.

Exactly, node's conventions are to allow a range of versions (semver compatible). True, if all dependencies were pinned, this wouldn't come up as often.

That also means that there would be a lot more updating when security issues are found.

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

#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, that's the obvious, easy way of doing this" it's not a package, it's a pattern. I can promise you, this was only ever added to packages because people wrongly assumed because since it's about "promises" (spooooky) it must be complex and worthy of packaging.

As someone who doesn't do front-end work regularly, but also sank about 3 consecutive weeks (~6-8 hours/day) in the last year into understanding generators, yielding, and promises... I can tell you, the actually scary part about all of this, is pretty much no one just reads the fucking docs or the code they're adding.

Moral of the story, especially in the browser: the reward of reading the code before adding it is enormous, you'd be surprised how often the thing you want is just a simple pattern. Taking that pattern and applying it to your specific use case, instead of imposing that pattern on your use case will give you giant wins.... Learn the patterns and you're set for life.

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

#145

Earlier quoted context omitted.

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

You can't use the very latest version of any software in Debian at all without adding a custom repository, at which point you have the same issue. So the comparison is not apples to apples.

How about a rolling release like openSUSE tumbleweed then? I have been using it for years, I generally update once a week and I have never broken my system due to an update. Never.

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

#146

Earlier quoted context omitted.

I second this, JavaScript Devs are near the bottom of the food chain, just above VB Devs. Myself as a Java developer is middle of the pyramid. The apex predators are embedded developers, followed by c Devs then game Devs.

The “food chain?” What do you mean by that?

[deleted]

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

#147

Earlier quoted context omitted.

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

You can't use the very latest version of any software in Debian at all without adding a custom repository, at which point you have the same issue. So the comparison is not apples to apples.

You can use Debian Unstable, or maybe just use stable and reliable dependencies so that your software is also stable and reliable. That would require putting in some effort, though, and we can't be having that, can we?

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

#148
post #119

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 "magical security updates" theory has never worked. Breaking insufficiently-pinned dependencies are vastly more common than unnoticed fixes on patch releases. On balance, semver has been good for javascript, but to the extent it contributed to the popularization of this dumb theory it has been bad. Production apps (and by a transitive relation, one supposes, library modules) should be zealously pinned to the fewest possible dependencies, and those dependencies should be regularly monitored for updates. When those updates occur, tests can be run before updating the pins.

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

#149

The problems that beset the Javascript ecosystem today are the same problems that beset the Unix ecosystem, back in the 90s when there still was one of those. TC39 plays the role now that OSF did then, standardizing good ideas and seeing them rolled out. That's why Promise is core now. But that process takes a long time and solutions from the "rough consensus and running code" period stick around, which is why instan…

Then again, this broke a package that, by its very nature, isn't running in production. And the problem was solved within three hours.

So I'm not sure how much everything-used-to-be-great-nostalgia is justified here.

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

#150
post #137

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…

What do Rust idioms have to do with Javascript?
Post reply on HN