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

371–380 of 478 posts

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

#371

Post by lmm »

sosodev wrote: post #355
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…

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.

Vendoring causes more problems than it solves. There are plenty of things that could be improved about the node ecosystem, but a lot of the criticism isn't based on logic; there seems to be a large population on HN who just inherently hate large numbers of dependencies and will grasp for any excuse to justify that hate.

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

#372

Post by mtone »

jakear wrote: post #282
halfmatthalfcat wrote: post #230

Earlier quoted context omitted.

Deno was always Typescript-first fwiw

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…

On the other hand, trying to setup a typescript monorepo with shared/dependent projects is a huge pain since everything needs to be transposed to intermediary JS that severely limits or breaks tooling.

Even TS project references make assumptions about the contents of package.json (such as the entry file), or how the compiler service for VsCode preloads types from @types/ better than for your own referenced projects, which sadly ties TS to that particular ecosystem.

Language version compatibility is a good point, but perhaps TSC could respect the compiler version and flags of each package's tsconfig.json, and ensure compatibility for minor versions of the language?

Since I enjoy working in TS I'm willing to wait it out as well, the pros far outweigh the cons. Now that GitHub/MS acquired NPM, I have hopes that it will pave the way to make TS a first-class citizen, though I don't know if Deno will be part of the solution or not.

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

#373

Post by dylan604 »

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 personal data for monetizing. The web is also broken with other variations of constant tracking. I'm of an age where I remember time before the internet, so I'm not as addicted as younger people.

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

#374

Post by jakear »

mtone wrote: post #372
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…

On the other hand, trying to setup a typescript monorepo with shared/dependent projects is a huge pain since everything needs to be transposed to intermediary JS that severely limits or breaks tooling. Even TS project references make assumptions about the contents of package.json (such as the entry file), or how the compiler service for VsCode preloads types from @types/ better than for your own referenced projects,…

> TSC could respect the compiler version and flags of each package's tsconfig.json

That’s the problem - there is no tsconfig.json. You’re only importing a single URI.

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

#375

Post by mtone »

jakear wrote: post #374
mtone wrote: post #372

Earlier quoted context omitted.

On the other hand, trying to setup a typescript monorepo with shared/dependent projects is a huge pain since everything needs to be transposed to intermediary JS that severely limits or breaks tooling. Even TS project references make assumptions about the contents of package.json (such as the entry file), or how the compiler service for VsCode preloads types from @types/ better than for your own referenced projects,…

> TSC could respect the compiler version and flags of each package's tsconfig.json That’s the problem - there is no tsconfig.json. You’re only importing a single URI.

I see. While I don't know the details, it seems it would promote the use of "entry/barrel" files once again.

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

#376

Post by earthboundkid »

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.

How is it a lead balloon? Go got super popular in the period before /vendor and Dep (later modules). Yes, people wanted and got versions too, but the URL part stayed. ISTM, they had a Pareto optimal 20% piece of the puzzle solved and bought them selves time to solve the other 80% years later.

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

#378

Post by hombre_fatal »

Ndymium wrote: post #306
Pfhreak wrote: post #226

Earlier quoted context omitted.

What's the difference between a utility file and a package? That seems like a distinction without a difference to me. If you use the same one liners in more than one project and you copy that utility file over, the line gets even fuzzier.

The utility file will never be updated and break your build without you doing it yourself.

Also you can just read the code the same way you read any other code. And since it's in your codebase and git diffs, you will read it.

Because the implementation detail of is-promise actually is important. It just checks if an object has a .then() method. So if you use it, it's just as important that you know the limitation.

Not everything needs to be swept under the rug.

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

#379

Post by hombre_fatal »

exogen wrote: post #336
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…

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…

Though, let's also appreciate just how niche that case is. I'd be surprised if more than 0.5% of the JS devs reading this will ever encounter that scenario where they are reaching across VMs like that in their life.

`obj instanceof Promise` and `typeof obj.then === 'function'` (is-promise) are much different checks. Frankly, I don't think either belongs in a library. You should just write that code yourself and ponder the trade-offs. Do you really just want to check if an object has a then() method or do you want to check its prototype chain?

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

#380

Post by nitsky »

jakear wrote: post #282
halfmatthalfcat wrote: post #230

Earlier quoted context omitted.

Deno was always Typescript-first fwiw

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't update unexpectedly.

> Or, I’m using strictNullChecks. Dependent package isn’t.

This definitely sounds like a potential problem. Because Deno enables all strict checks by default, hopefully library authors will refrain from disabling them.

Post reply on HN