Internal types in @aws-appsync/utils differ from published types

[elieux]

It seems that recently (sometime this month I guess) AppSync started using updated type definitions in the package @aws-appsync/utils internally and the package published on NPM is left out of date. The type that started breaking our builds is Context, which is now generic (with stricter defaults than the previous non-generic type).

Our code that is now being rejected by AppSync looks like this:

import { util } from '@aws-appsync/utils';

/**
 * @param {import('@aws-appsync/utils').Context} ctx
 * @returns {import('@aws-appsync/utils').DynamoDBPutItemRequest}
 */
export function request(ctx) {
  const user = util.dynamodb.toDynamoDB(ctx.stash.userId); // AppSync says: error TS2339: Property 'userId' does not exist on type '{}'.
  // ...
}

/**
 * @param {import('@aws-appsync/utils').Context} ctx
 * @returns {unknown}
 */
export function response(ctx) {
  if (ctx.error) {
    util.error(ctx.error.message, ctx.error.type);
  }
  return ctx.result;
}

Specifying the type parameters makes it work again.

import { util } from '@aws-appsync/utils';

/*
 * @param {import('@aws-appsync/utils').Context<any, any, any, any, any>} ctx // local says: Type 'Context' is not generic. ts(2315)
 * @returns {import('@aws-appsync/utils').DynamoDBPutItemRequest}
 */

// ...

In order to make both local/CI and AppSync internal checks pass, we're doing a code transformation before deploying, but that's obviously not ideal. We're using version 1.1.0 of the package; https://www.npmjs.com/package/@aws-appsync/utils/v/1.1.0

[onlybakam]

this issue should be resolved now with latest version of APPSYNC_JS and utils package

[elieux]

Seems to be consistent now, thanks.

[perryn]

Hi @elieux and or @onlybakam

I hope you don't mind answering a question for me.

The way AWS seem to promote unit testing JS AppSync resolvers is to AppSync.evaluateCode from the AWS SDK which will as far as I can tell actually execute the resolver somewhere in AWS.

However, it seemed to me that it should be possible to test by running the resolver code locally rather than in AWS. (In fact, I assume thats WHY there is a published @aws-appsync/utils npm package)

reading between the lines of this issue, it seems like @elieux is indeed testing by running resolver code locally?

Can anyone confirm if this is a workable approach? Is it a good idea or is it best to stick to the evaluateCode approach?

Thanks