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

211–220 of 478 posts

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

#211

Post by jdlshore »

2OEH8eoCRo0 wrote: post #109
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…

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?

Checking them into your repo is called “vendoring” and it’s one way of solving the problem, yes. Personally, it’s my favorite approach. But it does have some challenges, as other commenters point out.

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

#212

Post by snazz »

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?

The "slow and steady" approach works well for mature or stagnant ecosystems, but only when the packages are small enough that distribution developers can reasonably backport security fixes. That clearly doesn't work with big programs like Chrome and Firefox, so they have to resort to shipping the latest ESR version.

Writing JavaScript on Debian is practically impossible without sidestepping the package manager in some way. In a lot of cases, the hacks you have to do to run up-to-date software on a distro like Debian decrease reliability significantly.

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

#213

Post by coffeefirst »

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

Yeah, in 10 years of Python and front end development, this is the most fragile ecosystem.

That's not a criticism of NPM, just the way it's being used today.

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

#214

Post by _630w »

gav wrote: post #33

Digging into the reason behind breakage, the change is this one: https://github.com/then/is-promise/commit/feb90a40501c8ef69b... Which adds support for ES modules: https://medium.com/@nodejs/announcing-core-node-js-support-f... However the exports syntax requires a relative url, e.g. ‘./index.mjs’ not ‘index.mjs’. The fix is here: https://github.com/then/is-promise/pull/15/commits/3b3ea4150...

I wonder why people won't use yarn zero installs. They are great for having a reproducible builds and can work offline. You can have a CI and git hook which checks your code before deployment or pushing to git.

Another way is to pin down the specific versions without ~ or ^ in the package.json so your updates don't break stuff.

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

#215

Post by jhanschoo »

choward wrote: post #151

Can someone help me understand why a library like this is even necessary? Can't you just wrap everything and treat it like a promise? const aPromise = Promise.resolve(1); const notAPromise = 2; Promise.resolve(aPromise).then((x) => console.log(x)); Promise.resolve(notAPromise).then((y) => console.log(y)); // Logs: // 1 // 2

For compatibility with old versions of JS without Promise, when libraries used thenables or a promise library.

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

#216

Post by drinchev »

dragonwriter wrote: post #208
drinchev wrote: post #194

Earlier quoted context omitted.

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.

Oh, the irony ... https://www.npmjs.com/package/is-falsy

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

#217

Post by drngdds »

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…

>Or, really, part of standard js, maybe.

I think this would be the solution. I feel like a lot of the NPM transitive dependency explosion just comes from the fact that JavaScript is a language with a ton of warts and a lack of solid built-ins compared to e.g. Python. Python also has packages and dependencies, but the full list of dependencies used by a REST service I run in production (including a web framework and ORM) is a million times smaller than any package-lock.json I've seen.

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

#218

Post by city41 »

devit wrote: post #209
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…

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 wr…

This function is most likely an artifact of before promises got standardized. One way promises took off and became so ubiquitous is different implementations could interop seamlessly. And the reason for that is a promise was defined as 'an object or function having a then method which returns a promise when called'.

Doesn't excuse the JS ecosystem and JS as a whole, which truly is a mess. But there's a history behind these things.

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

#219

Post by city41 »

degraafc wrote: post #55
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…

I'd say that it should rather be a part of the type system. Some kind of `obj isa Promise` should be the way to do this, not random property checks. But that's JS...

Promises were not always part of the standard and for many years were implemented in user space, by many different implementations. Using duck typing like this was the only way to allow packages to interact with each other, as requiring an entire stack to say only use Bluebird promises is not realistic at all.

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

#220

Post by LudwigNagasena »

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 !

Consider it a special function like "__init__" in Python. I think this is one of the problems with duck typing, existence of a public function introduces possible name collision onto the whole codebase.
Post reply on HN