NextJS 16 Support

[lyleunderwood]

Is this related to a new or existing framework?

Next.js

Is this related to a new or existing API?

No response

Is this related to another service?

No response

Describe the feature you'd like to request

Next.js 16 was just released. According to the amplify docs, next.js 16 is officially not supported. Seeing as a significant draw of Amplify is as an alternative hosting platform for next.js applications, and as our company is currently building an application on amplify / next.js, and seeing as next.js 16 offers significant ergonomic and performance improvements over next.js 15, I'd like to see official support for next.js ASAP. Failing that, I'd like to see a roadmap to supporting next.js 16.

Describe the solution you'd like

Official support for next.js 16.

Describe alternatives you've considered

N/A

Additional context

No response

Is this something that you'd be interested in working on?

• 👋 I may be able to implement this feature request
• ⚠️ This feature might incur a breaking change

[bobbor]

Hey @lyleunderwood

Thanks for opening the issue. NextJS 16 is definitely on our radar.
It has just been released at the beginning of the week.

We will have to check in depth where potential problems lie with NextJS 16 support.

I will mark it as a feature request and we'll come back to you as soon as we have results.

Cheers Philipp

[kylemh]

hey @SuperManfred did you try an upgrade to see if anything goes poorly or were you just warded off by the dependency range warning on install? I'm running Next.js 16 and Amplify and things seem to be working for me fwiw.

@bobbor if nothing in the adapter cares about the fact that middleware has been renamed to proxy by Next.js team, then I doubt you'll have issues supporting it.

[bobbor]

Yeah, so I did some checking and testing, and basically almost everything works fine.

Here are my results:

Overall

Next JS 16 support works in most use cases.

using webpack

When using webpack using the --webpack and or --no-turbopack flag, all is good.
no issues at all.

using turbopack

Amplify JS works. Amplify UI mostly too. The only exception is our @aws-amplify/ui-react-liveness package, when using turbopack.

What is the issue?
the liveness package uses @tensorflow-models/face-detection for, well, face detection and that depends on @mediapipe/face_detection and the way the first imports the latter breaks in turbopack. I investigated why that would be the case and found out that it is fixable.

So what can be done about it?
We have a couple of options here.

1. we could create a PR and fix imports/exports for turbopack (and not break webpack ofc.)
2. create a fork, apply the fix and use that instead.
3. switch to an alternative face-detection library.
4. officially not support turbopack and leave everything as is.

All of these options have certain implications and we (as AmplifyJS team) will take some time, and think what is best for us and you.

TL;DR

we just need to bump the NextJS range in our packages and then we can officially support Next 16, if it wasn't for face-detection.

---

We'll keep you posted.
Cheers Philipp

[lyleunderwood]

@bobbor did you happen to test the new cacheComponents functionality?

[bobbor]

hey @lyleunderwood

I have only scanned over the topic and the docs say the following:

When the cacheComponents flag is enabled, Next.js uses React's <Activity>
component to preserve component state during client-side navigation.

To me this indicates, that there should be no issue with enabling cacheComponents at all.
All base components have nearly no or very little state, and all connected components use <Provider />'s.

And since cacheComponents wraps components in an <Activity /> and that then just removes the component-output from the actual dom, but not the virtual one, it never unmounts them and all state should be preserved until "visible" again.

So, IMHO, AmplifyUI as well as AmplifyJS should work well out of the box.
Though I cannot guarantee it, as I have not tested it.

Cheers Philipp