foal g rest-api post results in "No overload matches this call"

[pratham2003]

Excerpt of the automatically generated code.

  async findPosts(ctx: Context) {
    const posts = await getRepository(Post).find({
      skip: ctx.request.query.skip,
      take: ctx.request.query.take
    });
    return new HttpResponseOK(posts);
  }

Following is the error generated related to skip and take

No overload matches this call.
  Overload 2 of 2, '(conditions?: FindConditions<Post> | undefined): Promise<Post[]>', gave the following error.
    Argument of type '{ skip: string | Query | (string | Query)[]; take: string | Query | (string | Query)[]; }' is not assignable to parameter of type 'FindConditions<Post>'.
      Object literal may only specify known properties, and 'skip' does not exist in type 'FindConditions<Post>'.ts(2769)

[LoicPoullain]

My guess it that it comes from the name Post. I think that in your code Post is both the name of the route decorator and an entity class, which causes the code to fail.

[mbernard-bocasay]

Hi,

I've the exact same issue on a fresh project with fresh rest-api generate

foal generate rest-api employe

Looks like skip and take waiting for number value, and ctx.request.query.skip is String | Query

On my side i've convert to

async findEmployes(ctx: Context) {
    let skip: number = 0;
    let take: number = 20;
    if(ctx.request.query.skip != undefined){
     skip =parseInt(ctx.request.query.skip.toString());
     take =parseInt(ctx.request.query.take.toString());
    }
    const employes = await getRepository(Employe).find({ skip: skip, take: take});
    return new HttpResponseOK(employes);
}

Don't know if it's the good way ...

[LoicPoullain]

Okay, so I found out why it worked before and why it doesn't work anymore.

This is a recurring problem with non-native TS libraries (here express): the types have been changed in a patch of @types/express without respecting the semantic versioning, which makes the new build fail.

[LoicPoullain]

Follow-up:

After one day of work, I ended up fixing this issue. The fix will be released with version 1.8 when #670 is merged.

The problem was coming from the last version of @types/express which introduced a typing error. We had many times this type of errors in the past because a @type/xxx package didn't follow semantic versioning and introduced bad breaking changes in a patch version.

To fix this, I defined a precise version of @types/express-serve-static-core to be used in the framework. Version 2 will probably not rely on external @types/xxx packages not to get these errors anymore.