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

231–240 of 478 posts

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

#231

Post by recursive »

enitihas wrote: post #206
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…

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

All of the packages you mentioned are maintained by the same guy.

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

#232

Post by gavinray »

morelisp wrote: post #121
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…

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 are incompatible, you're getting hurt because the React shit breaks and churns."

I find the fact that front-end has a fragmented ecosystem due to different frameworks completely absurd. We have Webcomponents, which are framework-agnostic and will run in vanilla JS/HTML and nobody bothers to use them.

Most frameworks support compiling components to Webcomponents out-of-the-box (React excepted, big surprise).

https://angular.io/guide/elements

https://cli.vuejs.org/guide/build-targets.html#web-component

https://svelte.dev/docs#Custom_element_API

If you are the author of a major UI component (or library of components), why would you purposefully choose to restrict your package to your framework's ecosystem. The amount of work it takes to publish a component that works in a static index.html page with your UI component loaded through a tag is trivial for most frameworks.

I can't tell people how to live their lives, and not to be a choosy beggar, but if you build great tooling, don't you want as many people to be able to use it as possible?

Frameworks don't have to be a limiting factor, we have a spec for agnostic UI components that are interoperable, just nobody bothers to use them and it's infuriating.

You shouldn't have to hope that the person who built the best "Component for X" did it your framework-of-choice (which will probably not be around in 2-3 years anyways, or have changed so much it doesn't run anymore unless updated)

---

Footnote: The Ionic team built a framework for the singular purpose of making framework-agnostic UI elements that work with everything, and it's actually pretty cool. It's primarily used for design systems in larger organizations and cross-framework components. They list Apple, Microsoft, and Amazon as some of the people using it in production:

https://stenciljs.com/

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

#233

Post by chrisan »

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.

There are tools out there (like npm audit) that can alert you to known vulnerabilities.

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

#234

Post by throwanem »

gpm wrote: post #181
throwanem wrote: post #169

Earlier quoted context omitted.

The language has everything to do with it, because the language is the locus of practice. Rust practice is whatever it is, and is apparently pretty free with the use of "then" as a method name, which is fine. Javascript practice isn't the same as Rust practice, and Javascript practice includes a pretty strong norm around methods named "then". That's why the next time I run into such a method, that doesn't belong to a…

It doesn't call into question the idioms of either language. It does call into question the idea of programmatically deciding whether or not something is a promise based on the assumption that the idiom was followed. People bounce around between languages, especially to javascript. An expert javascript dev might not call things "then" but the many dabblers might. Going back to the original point this is a footgun, no…

So your point ultimately is that duck-typing isn't ideal? I mean, I agree, but I'm not sure where this gets us that we weren't before.

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

#236

Post by papito »

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.

Someone rolls out code where a serious bug fell through QA cracks, and appears to be breaking a mission-critical path. Your biggest client is on the phone screaming FIX IT NOW. Three hours is an eternity.

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

#237

Post by thawkins »

colinbartlett wrote: post #129
btilly wrote: post #119

Earlier quoted context omitted.

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…

There are commercial tools like blackduck, sonartype/nexus which are used to sczn dependancies of not1 just node code, and highlite ourof date packages, known vulnerabilities, and license problems.

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

#238

Post by recursive »

fortran77 wrote: post #80
gombosg wrote: post #56

Earlier quoted context omitted.

I sincerely hope you're being sarcastic here.

Actually VHDL / Verilog programmers are on top of the food chain.

I don't know much about VHDL, but there seems to be a non-scientifically-measured negative correlation between the quality of candidates I've interviewed claiming VHDL experience vs. those without.

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

#239

Post by gramakri »

rubyn00bie wrote: post #144

Call me crazy, but... I don't add things to my projects without looking at the source. Mostly because it saves me from shit like this. If I see something is small enough, and easy enough to reason about, I'll just copy-pasta that motherfucker with a comment citing the source and date it was pasta'd (license permitting). Things like this are so not worth a package, ever, it's something when you see it you go "oh yeah,…

Do you also copy/paste the tests? https://github.com/then/is-promise/blob/master/test.js . Just curious, sometimes it's really not just about the code but that it's continuously tested as well.
Post reply on HN