Instead of being able to write around it, you’ve forced yourself into using it for everything.
Love Your Neighbor (It’s You in 6 Months)I might sound spastic since plenty of people are using Bluebird like this today, but it’s not something I’d recommend from my personal experience.
As soon as the industry changes and your app now uses legacy technology, you wanna be ready for change.
This is all about maintenance.
At some point, doing things the old way (or really, the wrong way) will make it more-costly to hire new developers.
And when you ask devs to work on the legacy code, based on my experience, they’re going to be hoping it’s temporary or that a rewrite is coming soon.
While you probably won’t want to use both the native implementation and Bluebird at the same time, my recommendation is to always import Bluebird where you want to use it and always name the imported library Bluebird to signal all developers “I’m using the Bluebird promise library”.
With a change like that, other devs won’t have to guess or constantly check if Bluebird was imported into each file every time they’re in one.
That way, you always know what kind of promise you had.
Now your app can be easily maintained and refactored over time without worrying about this looming Bluebird problem.
PromisifyLike bindCallback in RxJS, you can use Promise.
promisify to automagically wrap callback functions in a promise.
I used this method in the first version of my lights controller software at home since it got tiring converting callbacks to promises each time I wanted to use one.
On the other hand, I don’t recommend ever using Promise.
I get it has its uses, but it mutates the object you give it and well, I like to be explicit about these things especially because now you’re tying your regular libraries to Bluebird.
I don’t like changing the landscape of Node.
js libraries or your browser’s window object since developers down the line won’t know what the heck’s going on.
I CAN HAS ALL THE PROBLEMS?For instance, a developer might import fs expecting a native Node.
js library only to find every function has a custom promisified async version that returns a promise instead of taking a callback, and nothing in the codebase matches the official Node.
It’s a great way to confuse people.
And postfixing the promisified versions “async” makes it even more confusing because technically fs.
readFile is already async, but now there’s fs.
readFileAsync which is also async, but specifically promisified.
Why not fs.
readFilePromisified?.Too long?.Maybe you shouldn’t be mutating fs.
Take it another way, now there are two completely different ways of calling functions on native libraries.
Instead of wrapping those calls in your own utility file (also comes with its downsides), you’re relying on code reviews, possibly linting rules, and word-of-mouth to ensure devs are using the preferred methods.
That, or you’ll just have a large codebase containing a mishmash of various coding styles.
Always leaves a headache for the next dev who takes over and wonders why it’s done one way here and a completely different way in another place.
Bluebird predates this change, but latest docs also don’t warn against it; in fact, they encourage it.
Mutating libraries and global values like this is living legacy ever after.
It’s a great way to tie your project into a knot around a single library.
ConclusionI know this is controversial.
I expect devs using Bluebird to have their own horror stories, but the reality is, I’ll probably get a lot of negative feedback.
If you found flaws in my evaluation, I encourage you to provide your feedback so I know what to improve the next time I write an article.