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

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

#121

Post by morelisp » Sat, Apr 25, 2020, 6:19 PM UTC

throwanem wrote: post #107

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…

This analogy doesn't hold up at all.

The UHH is a fun read, yes, but the biggest real-world problem with the Unix Wars was cross-compatibility. Your Sun code didn't run on Irix didn't run on BSD and god help you if a customer wanted Xenix. OK, you can draw some parallel here between React vs. Vue vs. Zeit vs. whatever.

But there was also the possibility, for non-software businesses, to pick a platform and stick to it. You run Sun, buy Sun machines, etc. That it was "Unix" didn't matter except to the software business selling you stuff, or what kind of timelines your in-house developers gave.

There is no equivalent in the JS world. If you pick React, you're not getting hurt because Vue and React are incompatible, you're getting hurt because the React shit breaks and churns. Every JavaScript community and subcommunity has the same problem, they keep punching themselves in the face, for reasons entirely unrelated to what their "competitors" are doing. Part of this is because the substrate itself is not good at all (way worse than Unix), part is community norms, and part is the piles of VC money that caused people to hop jobs and start greenfield projects every three months for 10 years rather than face any consequences of technical decisions.

Whatever eventually hollows out the mess of JS tech will be whatever figures out how to offer a stable developer experience across multiple years without ossifying. (And it can't also happen until the free money is gone, which maybe has finally come.)

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

#122

Post by rsanek » Sat, Apr 25, 2020, 6:20 PM UTC

mikewhy wrote: post #111

staticassertion wrote: post #104

Earlier quoted context omitted.

Maybe I'm misunderstanding how those projects work. From what I recall, they generate a project, including the package.json. So I'm not sure why they couldn't just generate the package.json with pinned versions? I don't write much JS, and have only used create-react-app just a few times, so feel free to explain why this isn't possible.

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.

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

#123

Post by oefrha » Sat, Apr 25, 2020, 6:21 PM UTC

montroser wrote: post #108

mikewhy wrote: post #87

Earlier quoted context omitted.

> pin your dependency versions for projects running in production Works for existing apps, but people using create-react-app and angular CLI can't even start a new project.

Nah, create-react-app and others could easily pin dependencies of libraries they install in your new project to known-good versions. Without doing that bit of diligence, this type of issue should be 100% expected.

Then you can’t upgrade anything unless create-react-app releases a new version (or you eject), which, in addition to the obvious release cadence problem, might introduce other compatibility problems.

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

#124

Post by throwanem » Sat, Apr 25, 2020, 6:22 PM UTC

russtrotter wrote: post #105

is it idiomatic in the JS world to always express dependencies in the "version X.Y or higher", vs "version X.Y"? Most of my experience is from the java/maven world where you're playing with fire if you don't just make it "X.Y".

There are a lot of idioms. A very common one, I think the current default, is to pin only the major version in the dependency list, and also to lock exact versions in an installer-generated lockfile following a successful install. If you find a locked version breaks your code, you adjust your dependency list, nuke the lockfile, and let a reinstall build it again.

The idea is that pinning major versions lets you get non-breaking improvements from package authors who use semver properly, and pinning exact known-good versions lets you avoid surprises in your CI builds.

It works pretty well when you start from a known good state and vet your dependencies reasonably well. The trouble here seems to be largely that CRA is designed, among other purposes, to serve people just getting into the ecosystem of which it's a part, and those people are unlikely to be familiar enough with the details I've described to be able to effectively respond.

The comparison with left-pad is easy, but this isn't at all on the same scale. It's a bad day for newbies and a minor annoyance for experienced hands. And, of course, cause for endless spicy takes about how Javascript is awful, but such things are as inevitable as the sunrise and merit about the same level of interest.

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

#125

Post by mikewhy » Sat, Apr 25, 2020, 6:23 PM UTC

staticassertion wrote: post #77

mikewhy wrote: post #72

Earlier quoted context omitted.

> Or, really, part of standard js, maybe.see: It's a part of node, at least: https://nodejs.org/docs/latest-v12.x/api/util.html#util_util...

This will work for a standard Promise, which is great, but not for weirdo made up promises. It also was released, I think, in 2018. It's one thing if you own the entire codebase, but if you're building a popular, multiple-years-old library/framework, you can't make the same assumptions.

I'm only finding about it today TBH. Usually I go for what this library does:

  function isPromise(obj) {
    return typeof obj?.then === 'function'
  }

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

#126

Post by aylmao » Sat, Apr 25, 2020, 6:23 PM UTC

throwanem wrote: post #107

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…

> Deno appears to be trying to become the Linux of Javascript

Deno always sounded more "like the Plan 9 of Javascript" personally to be honest. It seems to be better (yay for built-in TypeScript support! Though I have my reservations about the permission management, but that's another discussion) but perhaps not better enough (at least just yet) to significantly gain traction.

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

#127

Post by montroser » Sat, Apr 25, 2020, 6:23 PM UTC

mikewhy wrote: post #114

montroser wrote: post #108

Earlier quoted context omitted.

Nah, create-react-app and others could easily pin dependencies of libraries they install in your new project to known-good versions. Without doing that bit of diligence, this type of issue should be 100% expected.

By doing that they would avoid this issue, for sure. They would also introduce security issues by using old versions. And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.

It's not like pinning means you can /never/ update. You just get to do it on your own schedule.

You can even automate updating to some degree -- running your tests against the latest everything and then locking in to those versions of all goes well.

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

#128

Post by vel0city » Sat, Apr 25, 2020, 6:25 PM UTC

exogen wrote: post #106

andrewzah wrote: post #86

Earlier quoted context omitted.

No. Other languages don't publish/import packages that are one line of code . I have never seen an issue like this with any other language that I've worked with. Any sane developer that needed a one-liner like this would just manually implement it. Not to mention that these sorts of functions are unnecessary in languages with a good stdlib or statically typed languages like rust, etc.

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?

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

#129

Post by colinbartlett » Sat, Apr 25, 2020, 6:28 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.

I’m working on a thing I’m calling DriftWatch that attempts to track, objectively, how far out of date you are on dependencies, which I call dependency drift. I’ve posted about it here before [1]. I’m using it in my consulting practice to show clients the importance of keeping up to date and it’s working well.

I agree with the parent that it’s important to lock to avoid surprises (in Ruby, we commit the Gemfile.lock for this reason), but it’s equally as important to stay up to date.

1. https://nimbleindustries.io/2020/01/31/dependency-drift-a-me...

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

#130

Post by alerighi » Sat, Apr 25, 2020, 6:30 PM UTC

staticassertion wrote: post #45

chvid wrote: post #7

And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; }

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 place), but then you want to check if the argument is a Promise, sure with `instanceof` the compiler knows that you are doing, otherwise not.

Also, look at the repo, a ton of files for a 1 line function? Really? You take less time to write that function yourself than to include that library. But you shouldn't have to write that function in the first place.