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

391–400 of 478 posts

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

#391

Post by recursive »

jakear wrote: post #385
nitsky wrote: post #380

Earlier quoted context omitted.

> I’m running my project with ts 3.6. Library upgraded to 3.7 and adds null chaining operators. Now my package is broken. Isn't this similar to not upgrading node and using an updated version of an npm package that calls a new function added to the standard library? All npm packages have a minimum node version, and similarly all deno code has a minimum deno version. Both use lockfiles to ensure your dependencies don'…

Node updates much less frequently than TS, so even if it was a problem before, it’s more of a problem now.

Not sure about that.

https://nodejs.org/en/download/releases/

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

#392

Post by erulabs »

dylan604 wrote: post #373
erulabs wrote: post #347

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. Sadly, I dream of doing this very thing every day. I'm at that notch on the thermometer just before "burned out". I love creating a working app from scratch. However, I'm so sick of today's tech. The app stores are full of useless apps that look like the majority of other apps whose sole purpose is to gather the user's…

Send me a message if you want - I'd love to share what I'm building with you, as it is intended to resolve that exact feeling. I sympathize entirely.

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

#393

Post by dylan604 »

erulabs wrote: post #392
dylan604 wrote: post #373

Earlier quoted context omitted.

>I'd trade in my JavaScript for J2EE about as fast as I'd quit tech and move up into the mountains. Sadly, I dream of doing this very thing every day. I'm at that notch on the thermometer just before "burned out". I love creating a working app from scratch. However, I'm so sick of today's tech. The app stores are full of useless apps that look like the majority of other apps whose sole purpose is to gather the user's…

Send me a message if you want - I'd love to share what I'm building with you, as it is intended to resolve that exact feeling. I sympathize entirely.

If it's a log cabin, just tell me where to be, and I'll show up with hammers and saws!

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

#395

Post by ashtonkem »

erulabs wrote: post #347

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…

Funny, I run an “enterprise” stack almost entirely made of Java. I wouldn’t trade it for NodeJS for the world.

Making upstream changes indeed would be very, very hard. But I never have to make upstream changes because they’ve spent quite a large amount of effort on stability.

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

#396

Post by andrethegiant »

acemarke wrote: post #281
jrochkind1 wrote: post #276

Earlier quoted context omitted.

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

That might be referring to Yarn's "offline mirror" feature. When enabled, Yarn will cache package tarballs in the designated folder so that you can commit them to the repo. When someone else clones the repo and runs `yarn`, it will look in the offline mirror folder first, and assuming it finds packages matching the lockfile, use those. This takes up _far_ less space than trying to commit your `node_modules` folder, a…

verdaccio aims to do this as a proxy: https://github.com/verdaccio/verdaccio

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

#397

Post by jakear »

recursive wrote: post #391
jakear wrote: post #385

Earlier quoted context omitted.

Node updates much less frequently than TS, so even if it was a problem before, it’s more of a problem now.

Not sure about that. https://nodejs.org/en/download/releases/

Rephrase: people use new TS features much more often than they use new Node features.

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

#398

Post by Thorentis »

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…

I think you're on the right track. We all (I hope) agree that stuff like this should be standardized. But that's not the same as "should be a package".

At the very least, W3, or Mozilla Foundation, or something with some kind of quasi-authority should release a "JS STD" package that contains a whole bunch of helper functions like this. Or maybe a "JS Extras" package, and as function usage is tracked across the eco-system, the most popular/important stuff is considered for addition into the JS standard itself.

Having hundreds of packages that each contain one line functions, simply means that there are hundreds of vectors by which large projects can break. And those can in turn break other projects, etc.

The reason, cynically, that these all exist as separate packages, is because the person who started this fiasco wanted to put a high a download count as possible on his resume for packages he maintains. Splitting everything up into multiple packages means extra-cred for doing OSS work. Completely stupid, and I'm annoyed nobody has stepped up with a replacement for all this yet.

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

#399

Post by gear54rus »

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…

No one uses them because SSR is either non-existent or clunky with them.

Ignoring a common use case when inventing something is a good way to get your shit ignored in turn. Which is what happened.

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

#400

Post by stagas »

exogen wrote: post #340
stagas wrote: post #253

Earlier quoted context omitted.

And it doesn't even check if it's a Promise. It's violating it's own naming contract. At least it should be called: isPromiseLike? To check if something is actually a Promise all you need to do is a `foo instanceof Promise`.

That won't work across window boundaries, since each window environment gets its own distinct version of Promise.

Then instanceof will break for all native objects. Who writes code that checks instances across window boundaries? This is flawed beyond the idea of how to properly check an instance, it's bad architecture - the result? This post, and probably more subtle bugs surfacing along the way.
Post reply on HN