perhaps deprecate the npm package?

[jimmywarting]

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.

[benjamingr]

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.

[jimmywarting]

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? 💁

[benjamingr]

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".

[benjamingr]

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)

[benjamingr]

Verified nothing (yet) on the NPM side but they're working on it.

[shanebdavis]

Bluebird still provides a ton of great functionality not built into Node/JS. For me that's Promise.then, myPromise.tap and myPromise.tapCatch. Regardless, rather than deprecating Bluebird, what I'd like to see is a modern version of Bluebird that maintains its functionality, but 100% builds on top of the modern runtime support for Promises rather than Bluebird's own promise engine.

(Having never looked at Bluebird's source, perhaps I'm making too many assumptions...)

[jsumners-nr]

@benjamingr I understand the desire to not pester users, but I think people do not "get the message" when there isn't that big billboard when they install dependencies. It's been a couple of years since this issue was opened, and I can say with surety that there is still a significant amount of usage of bluebird on modern releases of Node.js (e.g. v20).

[benjamingr]

and I can say with surety that there is still a significant amount of usage of bluebird on modern releases of Node.js (e.g. v20).

Yes but as a maintainer in both I care more about not breaking or annoying users than I do about fixing that quickly rather than letting it drag out, new projects probably adopt bluebird less and less and older code gets migrated.

[jsumners-nr]

I think the notice that q provided (kriskowal/q#866 (comment)) straddles these concerns quite well. It's really the only way we have to educate people.

[purplepenguin42]

Yes but as a maintainer in both I care more about not breaking or annoying users than I do about fixing that quickly rather than letting it drag out, new projects probably adopt bluebird less and less and older code gets migrated.

While I understand where you're coming from and genuinely appreciate how much you care about users, valid deprecation notices aren't annoyances, they're extremely important communications. Realistically, bluebird is never going to die out. It's last version was released ~5 years ago and it still receives ~22M downloads per week. In another 5 years, it's probably still going to easily be in the 10s of millions per week category.

Many developers simply copy/paste things between projects, templates that never get updated, tutorials and guides where people don't know any better, etc. Put another way, if this isn't a textbook example of what npm deprecation notices were built for, I honestly have no idea when anyone would ever use them. Please reconsider deprecating it on npm; it will help orders of magnitude more users than hurt.

[benjamingr]

While I understand where you're coming from and genuinely appreciate how much you care about users, valid deprecation notices aren't annoyances, they're extremely important communications. Realistically, bluebird is never going to die out. It's last version was released ~5 years ago and it still receives ~22M downloads per week. In another 5 years, it's probably still going to easily be in the 10s of millions per week category.

I know I'm also a Node maintainer but as a bluebird maintainer I have to do what's best for bluebird's users rather than push my agenda.

What I've been doing to try and help is coordinate through the cleanup discord, people have been super nice and have spent time PRing popular packages replacing bluebird with native promises https://discord.com/channels/1227627367204257852/1227653370945474590

Many developers simply copy/paste things between projects, templates that never get updated, tutorials and guides where people don't know any better, etc. Put another way, if this isn't a textbook example of what npm deprecation notices were built for, I honestly have no idea when anyone would ever use them. Please reconsider deprecating it on npm; it will help orders of magnitude more users than hurt.

Part of the philosophy has always been to annoy developers as little as possible and be as useful as possible - hence why bluebird has no deps, low overhead, good errors and good performance (not saying this so you use it - please don't, we've been able to upstream the important bits to Node).

---

I am open to other non-destructive ideas but I think PRing packages that have bluebird as a dependency and don't need it is a great step.

There are still valid use cases for bluebird (like people stuck supporting old platforms) and I don't want to create the false impression it's abandoned. Q was deprecated but it always had a different philosophy, also I've gotten complaints from people about that.