Live data from Hacker News

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

github.com

351–360 of 478 posts

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

#351

Earlier quoted context omitted.

Have fun telling that to your boss

I rarely justify technical decisions to my boss, and when I do, they smile and nod.

Same. My boss doesn't micromanage technical decisions.

Wouldn't work there otherwise.

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

#352
post #338
post #60

Earlier quoted context omitted.

In theory `x instanceof Promise` would work, but the reason for this package is that there are many non-standard Promise implementations in the JS world.

It wouldn't work even if everything were native – see my reply above.

That applies for browsers, yes (though I'd argue is a rare edge-case), but create-react-app is a Node.js application.

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

#353
post #336

Earlier quoted context omitted.

Your implementation is broken even if everything uses native Promises. I don't know how many times this exact thread needs to happen on HN (as it has many times before) until people realize their "no duh" implementations of things are actually worse than the thing they're criticizing. Make an iframe. In the iframe: > window.p = new Promise(() => {}); From the parent window: > window.frames[0].p instanceof Promise fal…

In case someone else is also confused by this, it seems that instanceof checks whether the objects prototype matches, and these prototypes are not shared across different contexts, which iframes are [0]. (Though I would still like to know why it works like this.) [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

For security reasons - you can modify the prototypes and you wouldn't want iframes to inherit that.

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

#354
post #73

I feel the real issue here is downstream package consumers not practicing proper dependency pinning. You can blame the Node ecosystem, the maintainer of the package, etc. but there are well-known solutions to prevent this kind of situation.

So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.

As a fellow commenter said, you would ideally use something like dependabot or greenkeeper/snyk.

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

#355

I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…

There’s no silver bullet you’re absolutely right, but does that mean there isn’t room for improvement? Or that you shouldn’t try? Dropping all dependencies is extreme for sure but to argue against something as simple as vendoring is a bit odd.

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

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

We run Dependabot in our CI pipeline to flag security upgrades, and then action them. I'd much rather have that manual intervention than non-deterministic builds.

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

#358
post #161

Earlier quoted context omitted.

The title doesn't strike me as clickbait. The significant thing is what happened.

Personally as a JS dev, the significant thing is which package it was. These stories happen all the time, so when I see them I’d rather know which package it is at a glance so I know if I’m affected.

Fun thing with building applications overusing npm is that you usually don't know exactly what packages you have. Not until you check for the specific package, so you probably don't "know at a glance" if you're affected or not.

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

#359

I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…

> I'd trade in my JavaScript for J2EE about as fast as I'd quit tech and move up into the mountains.

I think the snark is obscuring the point of this comment.

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

#360

I'm a developer, but I'm also on-call 24/7 for a Node.js application. The number of people here saying "this is why you don't use dependencies" or "this is why you vendor your deps" is frustrating to see. No one _but no one_ who has managed complex enough systems will jump on the bandwagon of enterprise-ready, monolithic and supported over something like Node.js. I'd trade in my JavaScript for J2EE about as fast as I…

There’s no silver bullet you’re absolutely right, but does that mean there isn’t room for improvement? Or that you shouldn’t try? Dropping all dependencies is extreme for sure but to argue against something as simple as vendoring is a bit odd.

You’re correct - there is room for improvement. The “npx” tool is a easy place to start! And absolutely agreed dropping dependencies is extreme and vendoring not so much - but in my experience vendoring often means “don’t ever touch again until a bad security shows up”. I was being a little bit too snarky in my comment tho, absolutely :)
Post reply on HN