I want to use bluebird's implementation of the Promise/A+ open standard and override native ES6 Promises. I also want the bluebird implementation to be available everywhere in my subsequently imported modules without having to require it in every single one of them. Bluebird's Getting started page tells me to:

var Promise = require("bluebird");

, which results in overriding the native Promise element. Because bluebird is a superset of the spec, it will not break existing code and is thus supposed to be safe to use.

However, because I know it's considered bad practice to:

1. extend or replace language natives, and
2. define globals for use in a require chain that depends on it

, I'm wary when I want to include this in the base script of a node app:

import Promise from 'bluebird';
global.Promise = Promise;

Is this a bad practice? Should I stick to importing bluebird in every single file?

I want to use bluebird's implementation of the Promise/A+ open standard and override native ES6 Promises. I also want the bluebird implementation to be available everywhere in my subsequently imported modules without having to require it in every single one of them. Bluebird's Getting started page tells me to:

var Promise = require("bluebird");

, which results in overriding the native Promise element. Because bluebird is a superset of the spec, it will not break existing code and is thus supposed to be safe to use.

However, because I know it's considered bad practice to:

1. extend or replace language natives, and
2. define globals for use in a require chain that depends on it

, I'm wary when I want to include this in the base script of a node app:

import Promise from 'bluebird';
global.Promise = Promise;

Is this a bad practice? Should I stick to importing bluebird in every single file?

• javascript
• node.js
• promise
• overriding
• bluebird

• 1 Just because I'm curious: Why do you want to override the base Promise implementation? – Justin Niessner Commented Jun 8, 2016 at 17:10
• 1 Generally faster, safer, better errors and incredibly helpful API add-ons. Check those out: bluebirdjs.com/docs/why-bluebird.html bluebirdjs.com/docs/api-reference.html – Christophe Marois Commented Jun 8, 2016 at 17:13
• 3 @CrescentFresh I think Christophe means that all required modules should also use Bluebird promises instead of native ones. – gcampbell Commented Jun 8, 2016 at 17:25
• 2 This is not opinion based, this is a library question. – Benjamin Gruenbaum Commented Jun 9, 2016 at 9:49
• 2 @gcampbell bluebird interops cleanly with other promise implementations, including native ones. – Benjamin Gruenbaum Commented Jun 9, 2016 at 9:49

1 Answer 1

I have done this hundreds of times in my code over the last 4 years and so have plenty others among the 10 million monthly downloads.

It is officially supported to swap the native implementation with bluebird.

I do

const Promise = require("bluebird");

On a per-file basis. Note that usuaslly you can promisify your APIs once and then generally avoid calling Promise - calling at most .resolve.