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

381–390 of 478 posts

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

#381

Post by jasonhansel »

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…

Sure, but JavaScript and J2EE aren't the only options. You can use a language with more built-in functionality, reduce the use of unnecessary external libraries, and/or limit those libraries to ones from trusted sources.

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

#382

Post by nitsky »

Rapzid wrote: post #262
mirko22 wrote: post #227

Earlier quoted context omitted.

> running code straight from wherever on the Internet it happens to live today. This, exactly this. Young me thought this was a point of the whole thingy we call Internet. And exactly that is what I like about QML from Qt. Just point to a file and that's it.

Go tried it; went over like a lead balloon. Theory; lead balloons don't fly anywhere.

Go still identifies packages by URL. The recent modules feature just added the equivalent of lockfiles like npm, yarn, cargo, etc. It also added some unrelated goodies like being able to work outside of $GOPATH.

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

#383

Post by cyral »

alerighi wrote: post #130
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…

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…

Are you saying that this isPromise package will not play well with TypeScript? One of those files (index.d.ts) solves the TypeScript problem using type predicates. TypeScript WILL know that the object is a promise if it returns true.

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

#384

Post by cyral »

__s wrote: post #184
alerighi wrote: post #130

Earlier quoted context omitted.

Lile... x instanceof Promise It works for standard promises, sure there are non standard promises, ancient stuff, that to me shouldn't be used (and a library that uses them should be avoided). So why you need that code in the first place? Also that isPromise function will not work with TypeScript, imagine you have a function that takes something that can be a promise or not (and this is also bad design in the first p…

TypeScript supports 'function f(x: any): x is T' as a way to declare that if f returns true, x may pass as type T https://www.typescriptlang.org/docs/handbook/advanced-types....

This package has an index.d.ts file that utilizes exactly this.

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

#385

Post by jakear »

nitsky wrote: post #380
jakear wrote: post #282

Earlier quoted context omitted.

I have doubts about how this could possibly work. The idea is you pull a .ts file directly, right? Then your local ts-in-debo compiles that to extract typedefs for intellisense/etc and the JS. What happens when it was created for a different version of typescript than what you’re running? Or if it was created targeting different flags that what you’re using? This will cause lots of problems: I’m running my project wi…

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

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

#386

Post by wolco »

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…

Shouldn't a js framework exist that includes these static basic if checks in the core and offers them as a buildin method? Why load this as an external package, why not copy the code and maintain locally?

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

#387

Post by dstaley »

This is a prime example of where I think GitHub's acquisition of Dependabot and npm could really pay off. Imagine being able to publish a prerelease version of your library and run the CI tests of your consumers, all from within the GitHub interface. Dependabot already tracks compatibility between versions, so this would be a natural extension of that.

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

#388

Post by TechBro8615 »

capableweb wrote: post #358
TechBro8615 wrote: post #200

Earlier quoted context omitted.

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.

Hah, true. I got bit by one of these two days ago where the offending package was trying to install node itself (wtf?). It was two levels deep of `yarn why` before I figured out the issue. Fortunately I've been around long enough that the first thing I did was check the package for github issues... sure enough, found a 5 hour old issue with a bunch of people complaining of failing builds. If I hadn't searched first, I probably would have banged my head for another couple hours...

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

#390

Post by ellis0n »

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…

I remember the beginning of React (before Webpack) when server compilation looks fine and that magic works as react.js in browser. This looks like new era where HTML is fixed. But no, we have 15 standards now. Everything is finished when I found Webpack 3-line module with 20 lines Readme description. We have 1000 modules and 1000 weak points after that. React has x1000 overhead

Any package and package manager has hot points:

- no standards, api connection issues (different programming styles and connection overhead)

- minor version issues (just this 1 hour bug 0-day)

- major sdk issues (iOS deprecate OpenGL)

- source package difference (Ubuntu/CentOS/QubesOS need a different magic for use same packages)

- overhead by default everywhere that produce multiple issues

Post reply on HN