[@types/bluebird] v3.5.21 exhausts the tsc compiler

[onury]

• I tried using the @types/bluebird package and had problems.
• I tried using the latest stable version of tsc. https://www.npmjs.com/package/typescript
• I have a question that is inappropriate for StackOverflow. (Please ask any appropriate questions there).
• Mention the authors (see Definitions by: in index.d.ts) so they can respond.
  • Authors: @lhecker

Latest bluebird types exhaust the tsc compiler.

• It takes extremely long to compile or even makes VSCode operate too slow.
• I read this post and then tried removing each module, one by one within node_modules/@types directory and it was bluebird definitely.
• Tried TypeScript versions 2.8.3, 2.9.1, 2.9.2 and next (nightly build). All the same.
• Happens with @types/bluebird v3.5.21
• Does not happen with @types/bluebird v3.5.20

[lhecker]

@onury The only difference between 3.5.20 and 3.5.21 is the addtion of this single line by @andnp:

diff --git a/bluebird-3.5.20/index.d.ts b/bluebird-3.5.21/index.d.ts
index 8ad5705..1e49e04 100644
--- a/bluebird-3.5.20/index.d.ts
+++ b/bluebird-3.5.21/index.d.ts
@@ -542,6 +542,7 @@ declare class Bluebird<R> implements PromiseLike<R>, Bluebird.Inspection<R> {
    * The new function will always return a promise that is fulfilled with the original functions return values or rejected with thrown exceptions from the orig
    * This method is convenient when a function can sometimes return synchronously or throw synchronously.
    */
+  static method<R>(fn: () => R | PromiseLike<R>): () => Bluebird<R>;
   static method<R, A1>(fn: (arg1: A1) => R | PromiseLike<R>): (arg1: A1) => Bluebird<R>;
   static method<R, A1, A2>(fn: (arg1: A1, arg2: A2) => R | PromiseLike<R>): (arg1: A1, arg2: A2) => Bluebird<R>;
   static method<R, A1, A2, A3>(fn: (arg1: A1, arg2: A2, arg3: A3) => R | PromiseLike<R>): (arg1: A1, arg2: A2, arg3: A3) => Bluebird<R>;

I personally don't see how this can cause such a slowdown. Do you or @andnp got any idea maybe?

Are you using the method function somewhere? Could you possibly try adding some type hints in these places?

[andnp]

In general, having function overloads can add some cost to the TS compiler. However, my primary codebase uses Bluebird.method 141 times and I notice no increase in compile time using TS2.9.2 between @types/[email protected] and @types/[email protected] right now.

My guess is that somehow adding this overload has caused some other tangential issue with your types, especially if you have any not type-checked JS in your project. For instance:

// file1.ts
export const func = Bluebird.method(() => 22);

// file2.js
import { func } from './file1';

func().then(console.log);

This would have been a type error before, but if you have checkJs turned off then it would have ignored the error and said that func() returns any instead of Bluebird<number> (in this contrived example). That means if func() should have returned a more complicated type, the TS compiler was saving a lot of time due to the any.

Even worse if this occurred in the middle of a large project that passes that inferred type around, then adding this overload may have opened the floodgates a bit.

---

With a little more information on how you are using Bluebird.method, I certainly wouldn't mind helping debug the performance issues. A few questions that might help debug this:

• How often are you using Bluebird.method?
• Do you use Bluebird.method with functions that take 0 args?
• Do you only have typescript in this project?
• What does your tsconfig.json look like? In the past, I've noticed that disabling noImplicitAny has caused performance spikes because certain changes would suddenly make TS able to infer large function chains that it couldn't previously infer.

[onury]

@lhecker, @andnp that's strange.

This happened in a huge code base with 5 linked projects. We don't use Bluebird.method anywhere.

Before the slow-down happened; the only change we made initially was refactoring projects to use sub-types within sub-types. e.g. Promise<A<B>>. However, @types/[email protected] was ok with this but not the latest.

Then we realized we don't make use of any Bluebird-specific feature so we just removed Bluebird dependency from the project all together; in favor of native Promise object. So unfortunately, I will not be able to re-inspect this in the same code-base.

@andnp we don't have any plain JS in the code. allowJs is turned off since we have declaration turned on. checkJs is also off. noImplicitAny is also off but as I said this is not the reason bec. it was always off even when we had bluebird and @types/[email protected] dependency with normal performance.

[andnp]

Good to hear that there isn't any JS, that certainly makes things a bit easier. Perhaps I wasn't clear in my discussion on noImplicitAny though. Just because that hasn't changed doesn't mean that it isn't the root cause. For instance:

type X = // big expensive type

function identity(x: T): T { return x; }

function doThing(x) { // `x` here is implictly `any`
  // do some stuff with x here
  return x;
}

let x: X;

const y = doThing(x); // y is `any` implicitly.

then some gung-ho programmer comes in and adds typings to doThing and suddenly:

function doThing(x: X) {
  // still does stuff
  return x;
}

const y = doThing(x); // y is `big expensive type`

Although noImplicitAny never changed, the types for doThing did and caused a value that was any to be a big expensive type. Now imagine that y is used in multiple spots in the codebase, and you can see why this might cause a compile performance spike.

I brought this up in case I was the gung-ho programmer who made a tiny (seemingly harmless) change that opened these so-called floodgates by adding a new type to Bluebird.method. But now knowing that you don't even use Bluebird.method, this must be a tangential point.

---

Now that you've moved away from Bluebird anyways, I assume that your TS compile performance has gone back to normal? I'll keep my eye out for any compile performance degradation. My team tracks our compile times on every build, but so far we've not seen any issue. Hopefully, this was just some highly edgy case that other users won't experience.

If not: welcome future user, you've come to the right place to debug this issue ;)

[onury]

@andnp Thanks for your detailed reply. We're now using native Promise in these projects but still using Bluebird in some others :)

I said I'm sure noImplicitAny is not the source bec. we didn't change any code and tsconfig. And @3.5.21 had slow performance, @3.5.20 did not.

Thanks anyway. Let's see if others experience this issue.

[orta]

Hi thread, we're moving DefinitelyTyped to use GitHub Discussions for conversations the @types modules in DefinitelyTyped.

To help with the transition, we're closing all issues which haven't had activity in the last 6 months, which includes this issue. If you think closing this issue is a mistake, please pop into the TypeScript Community Discord and mention the issue in the definitely-typed channel.