Support Next.js 12

[quinnturner]

Next.js v12 was just announced by Vercel. This issue is requesting for Next.js v12 support on Amplify Hosting.

Here's a checklist for general support. Some of these may Just Work ™️ out of the box; I haven't tested much.

• Basic v12 support (my non-/api-using app seems to work out of the box. It still uses Babel, would be good to confirm with an app building with swc)
• React 18 support: native Next.js APIs & Suspense
• Native ES Modules support
• Middleware support (beta) (with Lambda@Edge)
• <Image /> AVIF Support: Opt-in for 20% smaller images
• Bot-aware ISR Fallback: Optimized SEO for web crawlers
• URL imports (alpha)
• React Server Components (alpha) with Next.js at the Edge

Known issues at this time:

• /api routes can result in Module not found errors, likely related to Webpack 5 (see Next SSR Support does not work with imported files #1872), thanks @brainer1

[andrewgadziksonos]

For React18, does AWS Lambda support NodeJS streams? Searching around the internet seems to suggest they dont.

For reference, reactwg/react-18#22

[brainer1]

we get a 503 error while attempting to access our /apis after upgrading to next12. we didn't change anything besides the upgrade. does anyone have a clue to why this might be happening?

[quinnturner]

we get a 503 error while attempting to access our /apis after upgrading to next12. we didn't change anything besides the upgrade. does anyone have a clue to why this might be happening?

Post CloudWatch logs if you can 😄

[brainer1]

2021-10-27T19:13:15.108Z	7b7ebdab-3a1d-4e16-9435-ab5ffe689052	ERROR	Invoke Error 	{
    "errorType": "Error",
    "errorMessage": "Cannot find module '../../webpack-api-runtime.js'\nRequire stack:\n- /var/task/pages/api/use-number.js\n- /var/task/index.js\n- /var/runtime/UserFunction.js\n- /var/runtime/index.js",
    "code": "MODULE_NOT_FOUND",
    "requireStack": [
        "/var/task/pages/api/use-number.js",
        "/var/task/index.js",
        "/var/runtime/UserFunction.js",
        "/var/runtime/index.js"
    ],
    "stack": [
        "Error: Cannot find module '../../webpack-api-runtime.js'",
        "Require stack:",
        "- /var/task/pages/api/use-number.js",
        "- /var/task/index.js",
        "- /var/runtime/UserFunction.js",
        "- /var/runtime/index.js",
        "    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:889:15)",
        "    at Function.Module._load (internal/modules/cjs/loader.js:745:27)",
        "    at Module.require (internal/modules/cjs/loader.js:961:19)",
        "    at require (internal/modules/cjs/helpers.js:92:18)",
        "    at /var/task/pages/api/use-number.js:198:27",
        "    at Object.<anonymous> (/var/task/pages/api/use-number.js:204:3)",
        "    at Module._compile (internal/modules/cjs/loader.js:1072:14)",
        "    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1101:10)",
        "    at Module.load (internal/modules/cjs/loader.js:937:32)",
        "    at Function.Module._load (internal/modules/cjs/loader.js:778:12)"
    ]
}

[brainer1]

i'm suspecting that it has to do with next-transpile-modules but i'm not sure. i'm going to remove an import that i think depends on it from that file and see what happens

[brainer1]

tried to upgrade to next-transpile-modules-v9 but still the same result

probably related to this: #1872

perhaps it's time to fully support webpack 5?

[hughesjj]

If we're using latest in our nextjs amplify app build settings, is there any way to peg it to 11 instead of falling back to ex 10, or having it pick up 12 whenever you release it?

I currently have the following environment variable set in my amplify application. When trying to set the version to "11" earlier this year, it would give me an error/unexpected behavior.

_LIVE_UPDATES: '[{"pkg":"next-version","type":"internal","version":"latest"}]',

[madeupname]

It seems to me that at a minimum, the docs should be updated to state v11 is the highest you can use. I had posted a problem to StackOverflow and it seems the solution is roll back to 11:

https://stackoverflow.com/questions/70219534/next-js-run-dev-fails-with-error-object-object

Or possibly, from the previous comment here, roll back to Webpack 4.

But as a new user, it sounds like if I want to use Amplify it'll be easier for me to stick with basic React and ditch Next.js.

[Danetag]

Hi team! Is there a roadmap/release date regarding the support of Next 12? Thanks!

[michaelangeloio]

@Danetag Second this question. Any update?

[MichalBunkowski]

Any updates?

[calexandru]

Any updates on this?

[drmzio]

Updates on this? @swaminator

[Ahmad-Jamal]

kindly update on this ? @swaminator

[hughesjj]

I don't think we're getting this functionality until Next.js (Vercel) themselves get their own house in order. There's a bunch of unstable functionality in their spec, and there doesn't exist a replacement tool for their export serverless target.

See: https://nextjs.org/docs/advanced-features/output-file-tracing

This is not unique to amplify, as nextjs-serverless is having similar issues

See also

• Next.js API routes (and pages) should support reading files vercel/next.js#32236 (comment)
• NextJS 12 results in less standalone setup for serverless environments than NextJS 11 vercel/next.js#33275

[carlosriveroib]

Well, redirects and image plugin is from NextJS 11 and it's not working on Amplify

[hughesjj]

@carlosriveroib I'm not sure what NextJS 11 has to do with this issue, but since we've broached the subject of whinging..

After bashing my head against nextjs since 2019, my current take is that it's actually hot garbage. They keep cramming new features into every release but rarely fix long standing, wide impact bugs from several versions ago, and often introduce new ones upon new release. There's a lot of cool ideas and fun tech in Vercel's product, but for something on version 12 it still feels like more of a beta product than any framework I've worked with in recent memory (that's above a 1.0 release).

I don't plan to write any "production" code on nextjs for any new products going forwards, and it's given me enough of a headache that I'm not enjoying it for personal projects either. This is without using amplify btw, I went to trying raw lambda and docker at different points.

I'm not saying I haven't had my own struggles with amplify, but I am saying many of the things I was "mad" at amplify for ended up being nextjs issues when I dug deeper or tried to do it myself.

At this point, I'm deciding what to switch to for my personal projects, not whether to switch.

@ your problem:
I would sincerely look to vercel first if you're having an issue. In my experience, it's more likely than not the problem is on Vercel's end. I would love for amplify to give us better insight into what nextjs is doing, especially during the build process. Being able to see a snapshot of the file system during build failure would be awesome. I understand it's serverless and thus there is no "one" filesystem, but still.

[dottodot]

Netlify supports nextjs 12 https://github.com/netlify/netlify-plugin-nextjs/blob/main/docs/release-notes/v4.md so I would have thought it is possible

[413n]

+1

[hughesjj]

@dottodot

Netlify supports nextjs 12 https://github.com/netlify/netlify-plugin-nextjs/blob/main/docs/release-notes/v4.md so I would have thought it is possible

It's possible (since Vercel themselves support it), but it's DIY and unstable. Per their contract, they could totally break/change their nft.json logic in a minor version update. They used to have a "serverless" target spec Amplify/Serverless/Netlify could work against, but they deleted it without providing equivalent supported functionality in nextjs 12.

So, Amplify could try to roll their own interpretation of the logic, but then any minor update may break every user of nextjs ISR on amplify. Amplify could peg to a "Compatible" version, but that would make applying security patches (something not uncommon for nextjs) arduous, could be "wasted work" if Vercel changes the spec again (which, imho is likely), and could cause further work for Amplify customers if they need to expose an amplify-specific contract for interoperability.

If they do end up supporting it natively, I'd really prefer they mark it "BETA" of some sort so that it's obvious to end customers like me that we shouldn't rely on it as a stable, production system. Once again I really love the ideas that Vercel is putting out with NextJS and where they're taking the front-end community as a whole, but as-is I wouldn't bet my career or company on NextJS for any core functionality given how immature their software lifecycle is.

If I were the VP/SVP of AWS mobile, I'd be looking to setup a paid support contract with Vercel for NextJS. It'd be cheaper than trying to constantly work around Vercel, give me as a customer of Amplify more confidence in using NextJS on their platform, would differentiate AWS Amplify from other providers and frameworks by virtue of having contractual support, and introduce some goodwill to offset AWS' past shady business with e.g. elasticsearch

I will note that next export for static sites should still work a-okay for nextjs 12, it's just the ISR and "serverless" targets which are problematic.

[wottpal]

@brainer1 have the same issue you described. did you find any workaround in the meantime?

[Alek-S]

+1

[DavideCarvalho]

Just leaving our experience about NextJS 12 on Amplify.

On my team we have a NextJS app with a custom .babelrc. Since we have a custom .babelrc, we don't use swc.

We figured it out that Amplify can handle NextJS until version 12.0.7 without using swc

Upgrading to 12.0.8, we started having @brainer1 error. We activated "AMPLIFY_NEXTJS_EXPERIMENTAL_TRACE", and the error stopped, everything was working as it should.

Trying to upgrade to 12.0.9, 12.0.10 and 12.1.0, we started having this strange error (see below)

{
    "errorType": "Runtime.UnhandledPromiseRejection",
    "errorMessage": "TypeError: Cannot read property 'headers' of undefined",
    "reason": {
        "errorType": "TypeError",
        "errorMessage": "Cannot read property 'headers' of undefined",
        "stack": [
            "TypeError: Cannot read property 'headers' of undefined",
            "    at Object.apiResolver (/var/task/node_modules/next/dist/server/api-utils.js:46:43)",
            "    at Module.<anonymous> (/var/task/chunks/884.js:42:34)"
        ]
    },
    "promise": {},
    "stack": [
        "Runtime.UnhandledPromiseRejection: TypeError: Cannot read property 'headers' of undefined",
        "    at process.<anonymous> (/var/runtime/index.js:35:15)",
        "    at process.emit (events.js:400:28)",
        "    at processPromiseRejections (internal/process/promises.js:245:33)",
        "    at processTicksAndRejections (internal/process/task_queues.js:96:32)"
    ]
}

[quinnturner]

If I've learned one thing about Next.js throughout my time deploying with Amplify, it's that Next.js has no qualms with breaking deployment behaviour that external services depend on between patches all the time. It's so frequent that it almost looks deliberate. With that in mind, I sympathize with the Amplify team delivering this functionality.

[b-bot]

If I've learned one thing about Next.js throughout my time deploying with Amplify, it's that Next.js has no qualms with breaking deployment behaviour that external services depend on between patches all the time. It's so frequent that it almost looks deliberate. With that in mind, I sympathize with the Amplify team delivering this functionality.

I have reason to believe that target:serverless was in fact intentionally deprecated to hinder alternative methods of deploying so as to not enjoy a first-class experience. For example any questions related to Amplify are ignored by the core team, see mine: vercel/next.js#22556

I appreciate the work the team is doing and understand this is purely a business decision since being acquired by Accel.

Let's face it, Amplify is almost identical to Vercel with higher configurability. The infrastructure behind it in fact runs on a mixture of AWS and Azure.

[hughesjj]

I concur with your point. That is the sense I have gotten from the situation by enumeration of the facts.

I think AWS (as a company) needs to pay Vercel if they want to continue using NextJS. It's dumb that people's lives on both sides of the fence are being wasted to intentionally make things harder, resulting in a significantly degraded customer experience and breach of trust for end users.

I believe this was karmatically bound to happen after what ElasticSearch (and various other loved open source products) had to endure when AWS started offering hosting for it without any compensation to the original developers. The Jig is up, the word is out, and I'd imagine every open source company is planning similar to avoid getting rug-pulled by AWS again.

My fear is that AWS leadership is going to be frupid and attempt to do what they did with elastic search, forking or otherwise trying to cut out the inventors of the tech in a strong-armed attempt to keep high profit margins and total control. A big difference here is that, while NextJS is widely used, it has no where near the install base Elastic Search did, and I can't imagine it would ever be profitable to do so.

I also believe AWS leadership won't care, and will grind as many talented engineers they can hire into the stone in a stubborn attempt to avoid actually paying people for their work, no matter how much it costs AWS. I'd further imagine these talented engineers would (rightfully) start diving from the sinking ship, incentivizing mangers to start putting any key "flight risks" on Focus (or even Pivot) plans so they can't transfer teams.

If that happens (preferably, well before such happens), I would sincerely hope the AWS Amplify engineering team takes a look at what new hires to AWS are getting via levels.fyi or the grapevine, realize that 360k base raise is only going to apply for the to 20% that are TT or promoted this year, won't actually cap out the 360k, and will be significantly backloaded, and that their life and soul aren't worth wasting away in an unwinnable situation.

All that can be avoided if AWS simply negotiates a support contract with the inventors of NextJS and pays them for such an innovative product. I'm sure AWS leadership has an endless well of excuses for why they don't want to pay people for their labor. I'm also sure whoever pays the NextJS team at the moment would like to get money for their effort.

If I'm correct and AWS leadership fails to negotiate a contract, I'd be worried about the service being abandoned. Leetcode premium is pretty cheap, all things considered. So is educative.io and their grokking the systems design + advanced systems design + coding interview courses, if you get the yearly subscription. The expected value of a pay raise makes these resources objectively one of the best possible returns on investment you could ever do -- forget the stock market and crypto. It would be dumb for an engineer in a burnout situation not to explore those options, or even just take their vests and make an extended non-company paid sabbatical out of it. Considering WA state (where Amazon is headquartered) offers public healthcare, and the summer is coming up as I can tell from the sun I write this in, that would be a very tempting option for any burnout engineers.

I'm also worried that an exodus due to this NextJS situation could negatively affect other amplify products. I'd be surprised if there was a dedicated oncall rotation for NextJS-only amplify engineers. I'd imagine that cohort would be shared amongst a much larger pool, meaning NextJS issues would affect the entire L8/L10 or whomever they report to.

Much more likely, imho, would be for AWS Amplify to simply drop support for NextJS instead of dealing with them. That would be shocking to me, considering how even SimpleDB is still supported last I heard. Part of the value of AWS is that they don't drop features once supported, at least not without some long term burndown plan. I'm sure there are some examples I'm unaware of, and there's stuff like not supporting old versions of nodejs/python with AWS Lambda , but that's fundamentally different from dropping support for an entire product line which exists and receives frequent releases.

So yeah, as a customer this situation gives me significant pause for either using or recommending Amplify as a product to my peer network. While I'm sure the "small" issue of NextJS support is known by someone up the leadership chain, I'm worried the "larger" issue of not paying for open source software and the potential catastrophic issues resultant from such is either not fully, truly considered or realized by leadership.

It would be nice if AWS leadership could Think Big and show good Customer Obsession by Insisting on the Highest Standards and Delivering Results via paying people for their labor, even if it's a third party whose work they're using. If not, I'm concerned Amazon might not be Earth’s Best Employer. After all, Success and Scale Bring Broad Responsibility.

I'm glad Amazon has integrity and allows customers of AWS like me to voice my valid concerns without hiding or otherwise removing my admittedly critical commentary. Thank you for being a good person and having moral integrity, and not pressuring an H1B to censor critical commentary to save face. That's nice of you to not exploit people in a tender situation for your benefit, AWS.

[sync2920]

I have a newly hosted nextjs12 app. However, it builds but does not deploy.
It looks like the cloudfront distribution that is supposed to be created by amplify is not increasing either.
Any troubleshooting on this?

[ferdingler]

@sync2920 can I have your appId please?

[sync2920]

@ferdingler
Thank you for your reply.
The appId is "d3mzsawj4eee6l".
Best regards.

[calavera]

@sync2920 You might have reached the url too early. When I load your app now, it shows a 500 error coming from Next.js. You should be able to see the application logs if you go your application page, then click in "Monitoring", then "Amplify Hosting compute logs", then click the link that will take you to CloudWatch logs.

[ferdingler]

@sync2920 thank you. I can see that your app got deployed properly but it is throwing 5xx errors. Yes, check your logs in CloudWatch, you should be able to see what errors are happening in your SSR pages as @calavera suggests.

[sync2920]

@calavera @ferdingler
Oh...
When I upgraded my existing app to the new build system, no matter how many changes I made, the content in the page did not change, so I created a new app, but I guess I forgot to bring environment variables and other settings...
Thank you!

Could it be that the distributions created by amplify are no longer visible from the cloudfront page?

[calavera]

Could it be that the distributions created by amplify are no longer visible from the cloudfront page?

we don't create distributions in your account anymore.

[sync2920]

Thank you very much, I apologize for the inconvenience.

[renchris]

I updated with the migrate to web compute button, however, now, the web application through my customs domains don't work

mydomain.com goes to the secondary early-stage branch of my project
https://mydomain.com goes to an error page of

This site can’t be reached mydomain.com took too long to respond.
Try:

Checking the connection
Checking the proxy and the firewall
ERR_CONNECTION_TIMED_OUT

[ferdingler]

@renchris if you need to revert your App to the previous platform, you can run the following command using the AWS CLI:

aws amplify update-app --app-id {APP_ID} --platform WEB_DYNAMIC

and then run a build.

[mattmcdonald-uk]

Tested this morning with a Next.js app using v13 that was previously unable to deploy and everything worked perfectly! Great job everyone who made this happen! 🥳

[mxkxf]

Our Next.js v12 app build time (~4 mins) is a third of what it is on the current Amplify hosting (~12 mins), which is great to see!

Did a quick Lighthouse test and the perf scores (TTI, FCP, LCP) are all the same as our current production non-beta app.

Struggling to find any decent guides about setting up ISR though, can anyone help there?

[nonhaltingmadness]

ISR ist just getStaticProps with revalidate  on return   export const getStaticProps = async (context) => {       return {         props: {                     },         revalidate: NEXT_PAGE_REVALIDATION_TIME, // in  seconds     }; };             Mit freundlichen Grüßen,   Christian Müller     ---   <https://www.virtuera.dev/> Virtuera Development Christian Müller e.U. Mohsgasse 17-19 · 1030 Vienna · Austria Christian Müller ***@***.*** ***@***.***> Software Services Systems Integration Digital Design           From: Mike Francis ***@***.***> Sent: Thursday, 17 November 2022 10:23 To: aws-amplify/amplify-hosting ***@***.***> Cc: Christian Müller ***@***.***>; Manual ***@***.***> Subject: Re: [aws-amplify/amplify-hosting] Support Next.js 12 (Issue #2343)   Our build time (~4 mins) is a third of what it is on the current Amplify hosting (~12 mins), which is great to see! Did a quick Lighthouse test and the perf scores (TTI, FCP, LCP) are all the same as our current production non-beta app. Struggling to find any decent guides about setting up ISR though, can anyone help there? — Reply to this email directly, view it on GitHub <#2343 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVIN7VSCZR3MDLCXOBEAQRDWIX2QNANCNFSM5GYHQFGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** ***@***.***> >

[aurelien-gaillard]

The migration didn't work well for me.
I have 3 branches in amplify, master, test, demo.
the upgrade launch a build only on master branch with last commit message [App configuration change]
But when I check the result of this build, I have a version of my app which is 2 weeks old, corresponding to test or demo branch.

It looks like the upgrading is mixing up the attached branches.
I don't know what to do now. Disconnect/reconnect all branches ?

[sync2920]

The same thing was happening to me.
In my case, it was due to the fact that the "Rewrites and Redirects" were still set to redirect to the old cloudfront distribution.

[aurelien-gaillard]

It looks that making a manual click on Redeploy this version on all my branches solved the problem.
The "Rewrites and redirects" has been cleared in the process.

[ajest]

Could it be that the distributions created by amplify are no longer visible from the cloudfront page?

we don't create distributions in your account anymore.

Where do you create the resources? Are they no more visible for us anymore?

[michrome]

Could it be that the distributions created by amplify are no longer visible from the cloudfront page?

we don't create distributions in your account anymore.

Where do you create the resources? Are they no more visible for us anymore?

That's correct @ajest . A fully managed hosting infrastructure means fewer resources for you to manage in your AWS account.

[renchris]

How would I check where my Amplify URL "rewrites and redirects" to for which CloudFront distribution? How would I update it to reference back to the correct distribution?

[renchris]

I have also tried "redeploy this version". And also tried resetting my zone files with my domain provider. Both didn't solve my issue

[renchris]

I manually took the "Distribution domain name" of the correct CloudFront distribution resource (ex. a12bc3defghijk.cloudfront.net) and copied and paste it in the "Rewrites and redirects" tab under Amplify source address of /<> and destination address of ex. https://k32ji1hgfedcba.cloudfront.net/<>

So replaced https://k32ji1hgfedcba.cloudfront.net/<*> with a12bc3defghijk.cloudfront.net

[calavera]

@renchris please open a new issue with all the details about your app. Our support team can help you with that, but we need some additional information that can be lost in this thread.

[calavera]

We've published documentation about how to safely migrate along with information about how Next.js 12 features work with this change: https://docs.aws.amazon.com/amplify/latest/userguide/update-app-nextjs-version.html

[michrome]

I am pleased to share we have now launched support for Next.js 12 and 13. For more information, please see our blog post at https://aws.amazon.com/blogs/mobile/amplify-next-js-13

If you run into issues with Next.js 12 or 13, please open a new issue so we can track it specifically. Thank you everyone for your patience and support, particularly the generous beta testers. It's much appreciated.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[calavera]

Thanks everyone here from your feedback. We're locking this issue so new messages don't get lost in this very long thread. Please, make sure to read the migration guidelines before changing your production apps. If you need any assistance, don't hesitate to open a new issue. 🙏