Error after updating to 1.1.0

[Vija02]

On building with typescript, this error message is presented
error TS2339: Property 'createResolver' does not exist on type '(root: any, args?: {}, context?: {}) => Promise<any>'.
Is there anything that needs to be updated?
I've reverted to 1.0.3 for now

[thebigredgeek]

Oh weird. Let me look into this and get back to you

[nicky-lenaers]

Experiencing the same issue

[allanleonardjr]

Experiencing the same issue also.
As @Vija02 said, dropping back down to 1.0.3 works.

[serranoarevalo]

Same here, any fix for this?

[mringer]

I'm not able to reproduce this. Node 9 / Hapijs 17.

@Vija02 @serranoarevalo any chance you can provide a bit more info about your environments?

[Vija02]

I'm not using this library anymore. However, when i tried to recreate the error, I got this instead:
node_modules/apollo-resolvers/dist/promise.d.ts(2,40): error TS2304: Cannot find name 'PromiseConstructor'.

Reproduction:

yarn global add typescript
yarn add apollo-resolvers@1.1.0

index.ts

import * as apolloResolvers from 'apollo-resolvers'
export const baseResolver = apolloResolvers.createResolver(
	null,
	(root, args, context, error) => error,
)

tsc index.ts

[mringer]

@Vija02 thanks for that.

I poked around and it looks like the es6 shim types are required to make the PromiseConstructor visible.

yarn add @types/es6-shim

It may be something we want to add as a dependency.

[iangregsondev]

Hi,
Yes I can confirm this is still happening. I added the above shim. My code is

export const booksResolver = baseResolver.createResolver(
  // Extract the user from context (undefined if non-existent)
  (root:any, args:{}) => {
    return books;
  }
);

The error in my IDE is createResolver does not exist on type......

[iangregsondev]

Just to confirm, using node 8.9.1. Typescript 2.8.1

[mringer]

@appsolutegeek what does your tsconfig.json look like? Do you have your types and typeRoots configured?

[mringer]

OK it appears that this error is caused when the necessary built in type declarations are not provided to tsc. They should to be explicitly linked either in the tsconfig.json or by passing the --lib flag to tsc.

Like so:

tsc index.ts --lib es6

or configuring your lib and target in your tsconfig.json

"compilerOptions": {
    "target": "es5",
    "lib": ["es6"],
    ...
}

More info here, here and here

Closing this unless there are further questions.

[theGlenn]

@mringer The problem is that resolver.d.ts return a Promise typed with any

export declare const createResolver: (resFn: any, errFn: any) => (root: any, args?: {}, context?: {}, info?: {}) => Promise<any>;

Maybe adding concrete types could solve this issue for ts users.

[corydeppen]

@mringer Can this be reopened? From what I can tell, it's impossible to use this library when a TS project is using strict mode. While I don't see how the lib compiler option might affect this issue, I have "lib": ["esnext"] in my tsconfig.json and it makes no difference.

[mringer]

The lib compiler option matters because it informs tsc on which shims and type definitions it should include when it builds. If the shim containing the promise definitions isn't included in your build, your build will fail.

Did you use the command line flag? I saw some variance between various tsconfig.json options, but passing the flag to the tsc cli always built correctly.

@corydeppen if you have a build config that better accommodates end users feel free to submit a PR.

[corydeppen]

I believe I understand the purpose of the compiler option, but it doesn't seem relevant to the original issue, which I continue to see even with the lib option set to esnext. As @theGlenn reiterated, the return type is Promise<any>, which obviously doesn't have a createResolver property on it. Since the definitions are built from the source, it seems like the createResolver function needs to be modified so the generated definition exposes a createResolver property.

@mringer Do you have an example using this library in strict mode?

[mringer]

@corydeppen minimum compilable repo here

Using any or as keywords by definition tell typescript to ignore more specific type checking on an Object. Unless you have the noImplicitAny flag set, which as its name implies disallows calls which would implicitly return any as the type.

There may be an issue with extending Resolver which is itself a Function not an Object. But this specific error stack appeared to stem from TSC not being able to resolve Promise not any.

[theGlenn]

@thebigredgeek @corydeppen I proposed the pull request #33 10 days ago to add concrete types.

TSC inferring is limited because libraries are expected to manually export the right custom interfaces and classes or provide an index.d.ts.
Rewriting the library in TS without actually using concretes types definition seems pretty odd to me 🤔.

@mringer I'm not sure leaving users configuration define types exports interpretation is the way to go...