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…
A one-line package broke `npm create-react-app`
311–320 of 478 posts
Re: A one-line package broke `npm create-react-app`
#312And 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?
Re: A one-line package broke `npm create-react-app`
#313Call 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,…
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`
#314Earlier 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…
Re: A one-line package broke `npm create-react-app`
#315Earlier 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.
Not pinning dependencies is a security issue.
Re: A one-line package broke `npm create-react-app`
#316Earlier 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…
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`
#317And 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…
Re: A one-line package broke `npm create-react-app`
#318Why NPM?? What is the point?
Re: A one-line package broke `npm create-react-app`
#319Earlier 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.
Re: A one-line package broke `npm create-react-app`
#320Earlier 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.