Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

201–210 of 478 posts

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

#201

Post by jen20 »

jakear wrote: post #78
gombosg wrote: post #68

Earlier quoted context omitted.

Exactly. We use Renovatebot for the same purpose. It pins dependencies and creates PRs for updates. Amazing to see how often the builds break, even sometimes after minor updates. But at least we fix them before release, and not after... :)

Yep. One of the very nice things about npm/node versus python or go or some others is that package locks and dependency pinning is possible. But few people seem to use it. I’ve seen reports of people using a go library that gets a minor update and breaks their app, at which point they become SOL as go always installs the lad test version. I myself have been working in python projects where the dockerfile simply says…

It's not true that Go always installs the latest version of a dependency. `go get github.com/x/y@v1.3.4` installs v1.3.4 of x/y, assuming there is a tag matching that.

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

#202

Post by fludlight »

progval wrote: post #93
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.

This happens because libraries installed by create-react-app depend on many other libraries (1026 transitive dependencies as of today). As a comparison, Django, a large Python web framework, has only three dependencies (pytz, sqlparse, and asgiref), which don't have dependencies themselves

pytz is a great example here. Imagine a separate package for every time zone.

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

#203

Post by RussianCow »

ddevault wrote: post #147
RussianCow wrote: post #84

Earlier quoted context omitted.

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?

You can do that with NPM if you pin your dependencies to exact versions, which is the same solution that you would use for any other package manager, and basically what Debian and other Linux distros do for you. I don't know why you think this problem is somehow unique to NPM or the JavaScript ecosystem.

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

#204

Post by dragonwriter »

staticassertion wrote: post #156
alerighi wrote: post #130

Earlier quoted context omitted.

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…

1) I'm not defending the implementation of is-promise. I don't care to, I'm not a javascript developer. 2) > sure there are non standard promises, ancient stuff, that to me shouldn't be used If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.

> If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.

Well, you can, and in the JS ecosystem you'll often find cases where there are two libraries (or two broad classes of libraries) for a certain function that make different choices, one of which makes the simple, modern choice that doesn't support legacy, and one that does the complex, messy thing necessary to deal with legacy code, and which you use depends on your project and it's other constraints.

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

#205

Post by wutwutwutwut »

IAmEveryone wrote: post #149
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…

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.

My development environment is my production environment.

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

#206

Post by enitihas »

drinchev wrote: post #194
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…

Yeah, but the question is how far should we go with that. Should we do : const isFalsy = require("is-falsy"); const isObject = require("is-object"); const isFunction = require( "is-function" ); const hasThen = require( "has-then" ); function isPromise(obj) { return !isFalsy(obj) && ( isObject(obj) || isFunction(obj) ) && hasThen( obj ); } Just because the code line is more than 50 characters, doesn't mean that we nee…

I think all of the above might already be libraries on npm. From what I remember, npm has isInteger, isPositive, is-odd, is-even.

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

#207

Post by jhanschoo »

jcelerier wrote: post #51
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'; }

how does that make sense in any universe. Just because I have a function named "then" does not mean that my object is a promise. Maybe "then" is the name of a domain thing in my project, for instance a small DSL or something like that. arghhhhhh !

objects with a .then(...) methods are treated as though they have Promise semantics by the language

See Promise.resolve https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#208

Post by dragonwriter »

drinchev wrote: post #194
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…

Yeah, but the question is how far should we go with that. Should we do : const isFalsy = require("is-falsy"); const isObject = require("is-object"); const isFunction = require( "is-function" ); const hasThen = require( "has-then" ); function isPromise(obj) { return !isFalsy(obj) && ( isObject(obj) || isFunction(obj) ) && hasThen( obj ); } Just because the code line is more than 50 characters, doesn't mean that we nee…

isFalsy is just “!”; I don't think we need a new library for a more verbose way to express a one-character unary operator, no, nor does it meet the standard of “The problem it solves is not straightforward” proposed upthread.

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

#209

Post by devit »

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…

A function like this should not be something that anyone even thinks of writing or using.

In properly designed languages, values have either a known concrete type, or the interfaces that they have to support are listed, and the compiler checks them.

Even in JavaScript/TypeScript, if you are using this, you or a library you are using are doing it wrong, since you should know whether a value is a promise or not when writing code.

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

#210

Post by oldmanhorton »

hu3 wrote: post #196
bdcravens wrote: post #188

Earlier quoted context omitted.

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

There are alternatives to create-react-app. In fact, there are alternatives to React.

Have fun telling that to your boss
Post reply on HN