perhaps deprecate the npm package?
jimmywarting opened this issue · comments
Seeing as the npm package haven't been updated in two years and the suggestion in the "Readme -> Note" about using native promises when possible still stands, would it make sense to deprecate this package on npm?
I'm in the process of trying to refactor a package to using native promises, async/await and async iterators and it's sometime a risky business unknowingly if something dose some abnormal to the promise chain like tapping in and calling .delay(), .spread() or any of the other utilities after a promise chain.
I'm more okey with this kind of code:
return bluebirdPromise.delay(250)than something like
function foo() {
return Promise.resolve(123)
}
foo().delay(250).then(console.log)At any point i might refactor foo to a async/await and perhaps use native promises or async/await instead.
I think it would be better to depend on a spec'ed promise A+ polyfill instead.
beside, this bluebird promise did not have Promise.allSettled so i had to use globalThis.Promise.allSettled to avoid the imported bluebird-promise imported in at the top of the file.
maybe bluebird have run its course, and say that it's time to say goodby to bluebird?
you have done an amazing work with promises and made browser lookup to bluebirds promise tools and speed so a big thank you.
I don't want the 25+ million downloads to get a "This package is deprecated" message that will be bad developer experience for them.
If you want to push this I would go and suggest this to dependents of bluebird (I've done so and opened PRs in the past to replace bluebird when it was used only a little with native promises).
It's true that we upstreamed everything we can - the helpers to readable streams in Node.js, cancellation to all APIs with AbortSignal, async stack traces and performance.
If there are bugs they will still be fixed, if there are security issues they will still be fixed.
if something dose some abnormal to the promise chain like tapping in and calling .delay(), .spread() or any of the other utilities after a promise chain.
In general I avoid promise chaining mostly altogether in new code - this syntax mostly exists because there was no async/await back then.
beside, this bluebird promise did not have Promise.allSettled so i had to use globalThis.Promise.allSettled to avoid the imported bluebird-promise imported in at the top of the file.
That was actually added at some point (to bluebird) as an alias.
That was actually added at some point (to bluebird) as an alias.
Hmm, then i must have a outdated version of bluebird...
I don't want the 25+ million downloads to get a "This package is deprecated" message that will be bad developer experience for them.
i get what you are saying, wondering when that time will come for node-fetch myself.
maybe we can add something to @types/bluebird that some of the promise chain methods is best avoided and mark only some chain methods as deprecated? 💁
maybe we can add something to @types/bluebird that some of the promise chain methods is best avoided and mark only some chain methods as deprecated? 💁
Honestly it would be great if people just stopped using it (and stuff like Q) altogether. Bluebird is often the dependent of a dependent so I really don't want to show people a ton of deprecation warnings they can't really handle because libraries they use use it.
I'll ping Myles (he's a PM at NPM) and ask if NPM has a way to do a "less disruptive soft deprecation".
maybe we can add something to @types/bluebird that some of the promise chain methods is best avoided and mark only some chain methods as deprecated? 💁
Another good idea might be an ESLint rule that warns on these methods and then suggest adding it to the airbnb base config people use?
As a side note I really wish there was a way to port the warnings since they're the main thing still missing (though less so since async await became more dominant)
Verified nothing (yet) on the NPM side but they're working on it.