331–340 of 478 posts
As always: vendor your dependencies.
Does anyone know if there's a way to upgrade a dependency of a dependency of a dependency of a dependency of a dependency in my yarn.lock without actually editing the yarn.lock, and also, waiting for five packages to update their dependencies, especially if they're locked or specified by even one of the five in semver rules? For example: Running `yarn why is-promise` in a CRA app: `Hoisted from "react-scripts#react-d…
Per other comments in the thread, this is the primary use case for Yarn's "resolutions" feature: https://classic.yarnpkg.com/en/docs/selective-version-resolu...
Can someone help me understand why a library like this is even necessary? Can't you just wrap everything and treat it like a promise? const aPromise = Promise.resolve(1); const notAPromise = 2; Promise.resolve(aPromise).then((x) => console.log(x)); Promise.resolve(notAPromise).then((y) => console.log(y)); // Logs: // 1 // 2
> why a library like this is even necessary?
Do you know how to determine whether something is a Promise?
Wrong. Also the first few StackOverflow answers are wrong or incomplete.
You know what's better? Using the same library 3.4 million repos depend on, that is tested and won't break if you use a package-lock.
> Can't you just wrap everything and treat it like a promise?
Maybe. Maybe not. Treating everything as a Promise means you have to make your function asynchronous even if not necessary.
Earlier quoted context omitted.
The point is that different languages are best suited to different tasks. Javascript is a simple, very loosely typed scripting language with prototypal inheritance that was developed to be run in the browser. It's a DSL, not a general purpose programming language. Using it elsewhere for applications where another language with stronger and more expressive types would be more appropriate requires hacks like compiling…
> It's a DSL, not a general purpose programming language Sorry, but I fear that ship has sailed ;-) And I've heard JS was developed by someone who wanted to give us Scheme (you can't go more general purpose than that) but had to resort to a more "friendly" java-syntax. IMHO javascript would be a great general purpose language if the ecosystem wouldn't be such a mess.
I know, I know. If anyone needs me I'll be in the angry dome.
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…
Yeah, but the question is how far should we go with that. Should we do : const isFalsy = require("is-falsy"); const isObject = require("is-object"); const isFunction = require( "is-function" ); const hasThen = require( "has-then" ); function isPromise(obj) { return !isFalsy(obj) && ( isObject(obj) || isFunction(obj) ) && hasThen( obj ); } Just because the code line is more than 50 characters, doesn't mean that we nee…
isFalse would be != isObject would use typeOf isFucntion would use typeOf
Where a library becomes helpful is when you have:
* A real problem (none of those are real problems, and the npm packages for them are essentially unused jokes)
* A solution that is not intuitive, or has a sharp edge, or requires non-obvious knowledge, or does not have a preexisting std approach
Checking for a promise, given the constraints of having multiple types of promises out in the world, falls into both of those. Checking if something is falsey, when Javascript provides !, does not fall into either.
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…
Make an iframe.
In the iframe:
> window.p = new Promise(() => {});
> window.frames[0].p instanceof Promise
false
Earlier quoted context omitted.
1) I'm not defending the implementation of is-promise. I don't care to, I'm not a javascript developer. 2) > sure there are non standard promises, ancient stuff, that to me shouldn't be used If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that.
> If you're building a library, or maintaining one that's been built over many years, you can't easily make calls like that. Well, you can, and in the JS ecosystem you'll often find cases where there are two libraries (or two broad classes of libraries) for a certain function that make different choices, one of which makes the simple, modern choice that doesn't support legacy, and one that does the complex, messy thi…
Earlier quoted context omitted.
I'd say that it should rather be a part of the type system. Some kind of `obj isa Promise` should be the way to do this, not random property checks. But that's JS...
In theory `x instanceof Promise` would work, but the reason for this package is that there are many non-standard Promise implementations in the JS world.
I feel the real issue here is downstream package consumers not practicing proper dependency pinning. You can blame the Node ecosystem, the maintainer of the package, etc. but there are well-known solutions to prevent this kind of situation.
So you would exchange security for stability, if you use package pinning then you will end up with fosilized packages in your product, which will have all maner of security issues that have alresdy been fixed.
And the source code of the library is: function isPromise(obj) { return !!obj && (typeof obj === 'object' || typeof obj === 'function') && typeof obj.then === 'function'; }
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`.