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

271–280 of 478 posts

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

#271

Post by bandrami »

gavinray wrote: post #232
morelisp wrote: post #121

Earlier quoted context omitted.

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…

This is slightly off-tangent, but as someone who has written production software on the front-end (small part of what I do/have done) in: Vanilla -> jQuery -> Angular.js -> Angular 2+, React pre-Redux existence -> modern React -> Vue (and hobby apps in Svelte + bunch of random stuff: Mithril, Hyperapp, etc) I have something to say on the topic of: > "If you pick React, you're not getting hurt because Vue and React ar…

> nobody bothers to use them

Here's the sad but unavoidable truth: the main purpose of Javascript currently is to keep Javascript developers employed.

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

#272

Post by _jal »

rsj_hn wrote: post #248
throwanem wrote: post #225

Earlier quoted context omitted.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

That line of reasoning suggests progress isn't being made and we are just reliving the past.

There are multiple reasons for this failure mode, only some of them subject to social learning.

Part of the problem is a learning process, and indeed, I think the Javascript world should have learned some lessons - a lot of the mess was predictable, and predicted. Maybe next time.

But part of the problem is that we pick winners through competition. If we had a functional magic 8-ball, we'd know which [ecosystem/language/distro/OS/anything else] to back and save all the time, money and effort wasted on marketplace sorting. But unless you prefer a command economy, this is how something wins. "We" "picked" Linux this way, and it took a while.

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

#273

Post by rhizome »

throwanem wrote: post #225
x86_64Ubuntu wrote: post #195

Earlier quoted context omitted.

And your example is why we have the "lol javascript trash amirite" chorus, because as you've noted these problems were solved decades ago. Yet for some reason, the JS and npm ecosystems always seem to have some dependency dustup once or twice a year.

Yes, that's largely my point. I'm not sure why it is surprising to see an ecosystem, twenty-five or so years younger than the one I compared it to, have the same problems as that one did twenty-five years or so ago.

NIH Syndrome is a double-edged sword that persists regardless of innovations.

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

#274

Post by throwanem »

bandrami wrote: post #271
gavinray wrote: post #232

Earlier quoted context omitted.

This is slightly off-tangent, but as someone who has written production software on the front-end (small part of what I do/have done) in: Vanilla -> jQuery -> Angular.js -> Angular 2+, React pre-Redux existence -> modern React -> Vue (and hobby apps in Svelte + bunch of random stuff: Mithril, Hyperapp, etc) I have something to say on the topic of: > "If you pick React, you're not getting hurt because Vue and React ar…

> nobody bothers to use them Here's the sad but unavoidable truth: the main purpose of Javascript currently is to keep Javascript developers employed.

Spoken like someone who's never seen what people perpetrate in, say, Java.

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

#275

Post by dragonwriter »

drinchev wrote: post #216
dragonwriter wrote: post #208

Earlier quoted context omitted.

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

I'm not surprised it exists (and literally is just a more verbose, indirect way to invoke “!” that nevertheless is a 17 sloc module with a bunch of ancillary files that has one direct and, by way of that one, 17 second-order and, while I didn't check further, probably an even more ridiculous number of more distant, transitive dependendencies.)

I'm just saying it's neither necessary nor consistent with the standard for when a library is a good idea proposed upthread, so suggesting it as part of an attempt at reductio as absurdam on that standard is misplaced.

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

#276

Post by jrochkind1 »

_630w wrote: post #214
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.

What's "yarn zero installs"? Googling did not do it for me.

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

#277

Post by franciscop »

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...

From those commits, it seems this issue was fixed in 1h12min. That should be a new record, specially considering this is all volunteer work on a Saturday. While it's bad that things break, the speed at which this was fixed is truly amazing. A big thank you to everyone involved here.

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

#278

Post by bandrami »

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.

And everyone who just upgrades whenever possible gets to be victims of security exploits too.

Users of Debian Stable missed Heartbleed entirely. It simply never impacted them.

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

#279

Post by gpm »

throwanem wrote: post #264
gpm wrote: post #247

Earlier quoted context omitted.

I don't actually mind duck-typing. My primary point is just that you are mistaken when claiming that this bug could only be surfaced by malicious code. My secondary (somewhat implicit) point is that having an "is-promise" function is a mistake when there is no way to tell if something actually is or is not a promise. This library/function name is lying to the programmers using it about what it is actually capable of,…

I mind duck typing! That's why I'm so fond of Typescript, where everything that shows up where a promise should be is reliably either instanceof Promise, or instanceof something that implements Promise, or a compile-time error. Absent that evolved level of tooling, and especially in an environment still dealing with the legacy of slow standardization and competing implementations that I mentioned in another comment,…

So, I mind poorly implemented duck typing, I also mildly mind dynamic typing, but in principle I think static duck typing could be not bad.

With javascript promises in particular, the duck typing suffers from this unfortunate fact that you can't easily check if something can be awaited-upon or not. I don't think I really care if something is a promise, so long as I can do everything I want to to it. So I view the issues here as this function over-claiming what it can do, the limitation on the typesystem preventing us from checking the await-ability of an object, and the lack of static type checking. None of those are necessitated by duck typing.

I disagree that you're stuck with this best-effort function. It's perfectly possible to architect the system so you never need to query whether or not an object is a promise. Given the lack of ability to accurately answer that question, it seems like the correct thing to do. At the very least I'd prefer if this function was called "looks-vaguely-like-a-promise" instead of "is-promise".

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

#280

Post by _630w »

jrochkind1 wrote: post #276
_630w wrote: post #214

Earlier quoted context omitted.

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.

What's "yarn zero installs"? Googling did not do it for me.

Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies.

All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit them to version control. Unlike node_modules, they are much more smaller in size due to compression. You will have offline, fully reproducible builds which you can test using a CI before deployment or pushing code to repository

https://yarnpkg.com/features/zero-installs

Post reply on HN