Amplify services provided through withSSRContext have no type definition

[emilioschepis]

Describe the bug
When using withSSRContext in a Next.js project, the resulting object is of type AmplifyClass.

Inside of this object, Auth, API, DataStore, all have a type of any.

To Reproduce
Steps to reproduce the behavior:

1. Setup a basic Next.js TypeScript project.
2. Add a getServerSideProps method to the default page.
3. See code snippet below.

Expected behavior
Auth and all the other objects have the same types they have in their "client side" version.

Code Snippet

export const getServerSideProps: GetServerSideProps = async (context) => {
  const { Auth } = withSSRContext(context);
  // ---- ^ ---- Auth has a type of `any`.

  return {
    props: {},
  };
};

[sammartinez]

@emilioschepis, for clarity, were you following this setup guide we have for Next.js? Please let us know

[emilioschepis]

Hi @sammartinez ,

I was not following that setup guide directly, but the same applies to this section:
https://docs.amplify.aws/start/getting-started/data-model/q/integration/next#api-with-server-side-rendering-ssr

By adding that code to my component, API is still typed as any.

[quinnturner]

withSSRContext returns AmplifyClass, which has the type definition:

export declare class AmplifyClass {
    private _components;
    private _config;
    private _modules;
    Auth: any;
    Analytics: any;
    API: any;
    Credentials: any;
    Storage: any;
    I18n: any;
    Cache: any;
    PubSub: any;
    Interactions: any;
    Pushnotification: any;
    UI: any;
    XR: any;
    Predictions: any;
    DataStore: any;
    Logger: typeof LoggerClass;
    ServiceWorker: any;
    register(comp: any): void;
    configure(config?: any): {};
    addPluggable(pluggable: any): void;
}

Looking at the Amplify.js file on the main branch:

export class AmplifyClass {
	// Everything that is `register`ed is tracked here
	private _components = [];
	private _config = {};

	// All modules (with `getModuleName()`) are stored here for dependency injection
	private _modules = {};

	// for backward compatibility to avoid breaking change
	// if someone is using like Amplify.Auth
	Auth = null;
	Analytics = null;
	API = null;
	Credentials = null;
	Storage = null;
	I18n = null;
	Cache = null;
	PubSub = null;
	Interactions = null;
	Pushnotification = null;
	UI = null;
	XR = null;
	Predictions = null;
	DataStore = null;

	Logger = LoggerClass;
	ServiceWorker = null;
...
}

This is a fairly useless type definition.

[quinnturner]

withSSRContext(ctx).Auth should probably be typed as AuthClass.

As a current workaround, I am performing this:

import { withSSRContext } from "aws-amplify";
import { Auth } from '@aws-amplify/auth';

export const getServerSideProps: GetServerSideProps = async (ctx) => {
  const auth = withSSRContext(ctx).Auth as typeof Auth;

  let user: any;
  try {
    user = await auth.currentAuthenticatedUser();
    console.log('user is authenticated');
    // fetch some data and assign it to the data variable
  } catch (err) {
    console.log('error: no authenticated user');
  }
};

[emilioschepis]

That is how I solved the problem as well, it seems like the only option we currently have.
Does this also mean that the fix for this would be as simple as changing the type definition to be AuthClass or are there significant differences between the SSR and the client-side versions of the export that need specialized types?

[harrysolovay]

For good hygiene, might I recommend the following:

import { withSSRContext } from "aws-amplify";
- import { Auth } from '@aws-amplify/auth';
+ import type { APIClass } from '@aws-amplify/auth';

export const getServerSideProps: GetServerSideProps = async (ctx) => {
- const auth = withSSRContext(ctx).Auth as typeof Auth;
+ const auth = withSSRContext(ctx).Auth as APIClass;

  let user: any;
  try {
    user = await auth.currentAuthenticatedUser();
    console.log('user is authenticated');
    // fetch some data and assign it to the data variable
  } catch (err) {
    console.log('error: no authenticated user');
  }
};

[quinnturner]

APIClass does not exist on @aws-amplify/auth v3.4.0, which is the most recent version that does not succumb to a bloated bundle: #7313

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[quinnturner]

I don't think this stale, sorry if it is

[jimblanc]

We have published an RFC on our plan for improving TypeScript support in Amplify JS & would love to get your feedback & suggestions!

RFC: Amplify JS TypeScript Improvements

[cwomack]

The developer preview for v6 of Amplify has officially been released with improved support for TypeScript and much more! Please check out our announcement and updated documentation to see what has changed.

This issue should be resolved within the dev preview and upcoming General Availability for Amplify v6, but let us know with a comment if there are further issues.

[cwomack]

With the release of the latest major version of Amplify (aws-amplify@>6), this issue should now be resolved! Please refer to our release announcement, migration guide, and documentation for more information.