Live data from Hacker News

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

github.com

311–320 of 478 posts

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

#311

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…

That's quite interesting, although back in the day we did that for C dependencies that weren't packaged well, and it quickly ballooned the size of our repo since git has to treat tar balls as binaries. Even if you only update a few lines of the dependency for a patch version, you re-commit the entire 43 MB tarball (obviously that depends on the size of your tarball).

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

#312
post #296
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'; }

Does anyone know if it really needs the !!obj&& at the start? Isn't that redundant with checking that the type is either "object" or "function"? And is there a reason to use '!!' inside a conditional? Wouldn't obj&& do basically the same thing?

Unfortunately, that's not redundant, because `typeof null` returns "object":

https://2ality.com/2013/10/typeof-null.html

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

#313

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,…

> Call me crazy, but... I don't add things to my projects without looking at the source.

This is manageable when you are using Packagist, this is manageable when you are using Maven, where all dependencies are flat. When compatibility issues arise they have to be dealt with upstream.

This is NOT manageable when you are using NPM that will go fetch 30 different versions of the same package because crazy dependency resolution.

This is not a JS issue like people claim here, this is 100% a NPM issue because whoever designed this was too busy being patronizing on Twitter rather than making sensible design decisions.

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

#314
post #280

Earlier quoted context omitted.

Instead of node_modules containing source code of the packages, yarn generates a pnp.js file which contains a map linking a package name and version to a location on the disk, and another map linking a package name and version to its set of dependencies. All the installed packages are stored in zip form in .yarn/cache folder to provide a reproducible build whenever you install a package from anywhere. You can commit…

This is a great feature I did not know about, thanks I don't understand how it applies to the OP problem. Even without "zero installs", yarn all by itself with a yarn.lock already ensures the same versions as in the yarn.lock will be installed -- which will still be a reproducible build as long as a given version hasn't changed in the npm repo. (It looks to me like "yarn zero" is primarily intended to let you install…

[deleted]

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

#315

Earlier quoted context omitted.

Nah, create-react-app and others could easily pin dependencies of libraries they install in your new project to known-good versions. Without doing that bit of diligence, this type of issue should be 100% expected.

By doing that they would avoid this issue, for sure. They would also introduce security issues by using old versions. And this would do nothing for the fact that `npm install eslint && ./node_modules/.bin/eslint` was also failing.

Pinning dependencies might introduce security issues.

Not pinning dependencies is a security issue.

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

#316

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…

>Or, really, part of standard js, maybe. I think this would be the solution. I feel like a lot of the NPM transitive dependency explosion just comes from the fact that JavaScript is a language with a ton of warts and a lack of solid built-ins compared to e.g. Python. Python also has packages and dependencies, but the full list of dependencies used by a REST service I run in production (including a web framework and O…

This is correct. I post the same thing every time one of these JS dependency hell issues pops up, but it's the case because it's true: The problem is the lack of a standard library. It's not that people don't know how to write a left-pad function, it's that it's dumb to rewrite it in every project and then remember what order you put the arguments in, etc. So people standardize, but they're standardizing on millions of different little packages.

I think the effort that goes into all the JS syntax and module changes would be better put into developing a solid standard library first.

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

#317
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…

This function should absolutely NOT be a package. The problem is that JS has a very minimal standard library and despite tons of money going into the system, nobody's had the good sense to take a leadership role and implement that standard. In other languages you don't need to include external packages to determine the types of objects you're dealing with, or many other things.

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

#319

Earlier quoted context omitted.

create-react-app contains over 1000 packages. How long would it take to review all of those?

This sort of cavalier attitude where 1000 dependencies are yawn-inducing in their commonality is why I feel vindicated in never having wasted my time with this kind of ecosystem. Eventually the house of cards will come down. Let's all pray that it happens sooner rather than later.

When WebAssembly gets direct DOM access we'll finally have options and we'll no longer have to tolerate JavaScript. I expect the JS community will settle down and get somewhat saner after that, too.

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

#320

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…

This function should absolutely NOT be a package. The problem is that JS has a very minimal standard library and despite tons of money going into the system, nobody's had the good sense to take a leadership role and implement that standard. In other languages you don't need to include external packages to determine the types of objects you're dealing with, or many other things.

And there's an interesting discussion to be had if it shouldn't be one of those snippets that everyone copies from Stackoverflow instead. And how much trouble in other ways that alternative has caused.
Post reply on HN