Async functions always return native promises. Because of that we end up with bluebird promises (with extra features) mixed with native ones. This makes functions somehow unpredictable (not clear when converting to bluebird promise is required.) Also casting from one type of promises to another is super ugly (not worth the benefit.)
If someone really wants to use extras from Bluebird, it should be required explicitly, without replacing the global Promise.
The performance argument for Bluebird is not valid because: 1) we already use native ones (async functions), and 2) native promises are slower but not much in context of IO, 3) native promises are getting faster, making the performance difference even less relevant.
There are mainly 2 Bluebird feature that are used across the codebase, and that will require some changes:
.map(map) used to map multiple records from a DB query (we can make mappers work for arrays too so that we can .then(map) regardless of query result.
.catch(predicate, error(...)) and similar (will have a separate proposition for error handling that will not relay on non-standard .catch())
Async functions always return native promises. Because of that we end up with bluebird promises (with extra features) mixed with native ones. This makes functions somehow unpredictable (not clear when converting to bluebird promise is required.) Also casting from one type of promises to another is super ugly (not worth the benefit.) If someone really wants to use extras from Bluebird, it should be required explicitly, without replacing the global Promise.
The performance argument for Bluebird is not valid because: 1) we already use native ones (async functions), and 2) native promises are slower but not much in context of IO, 3) native promises are getting faster, making the performance difference even less relevant.
There are mainly 2 Bluebird feature that are used across the codebase, and that will require some changes:
.map(map)used to map multiple records from a DB query (we can make mappers work for arrays too so that we can.then(map)regardless of query result..catch(predicate, error(...))and similar (will have a separate proposition for error handling that will not relay on non-standard.catch())