Improve deployed memory footprint with different start commands

[karlhorky]

From Tim Neutkens:

One quick optimization you can do for your app is removing pnpm start and using output: standalone or changing the command to ./node_modules/.bin/next start instead, that saves about 50MB in RSS

Let's explore both of the options (output: standalone and ./node_modules/.bin/next start) to find out and document what the difference is, check whether they make a difference for our deployed applications, and also check whether we need to update either of our cheatsheet entries:

• Command Line (creating a Next.js app)
• Deployment to Fly.io

[ProchaLu]

in 5085c17 I updated the start script command to ./node_modules/.bin/next start.

TODO:

• Explore the 2nd option (output: 'standalone') from the Next.js docs and describe what the benefits/drawbacks are of that.
• Change all content to whatever we choose:
  • all GitHub workflows
    • including testing workflows
  • all build scripts
  • all cheatsheets
• If we decide to go for output: 'standalone', then change any content which has already been updated to use ./node_modules/.bin/next start:
  • the commit above
  • one example (also all other portfolio Playwright PRs): Switch from Cypress to Playwright next-js-portfolio-web#107

[ProchaLu]

output: standalone

The output:standalone option in Next.js tells the framework to create a standalone folder that contains only the necessary files for a production deployment, including select files in node_modules. This doesn't copy the public or .next/static folders by default, as these should ideally be handled by a CDN instead, although these folders can be copied to the standalone/public and standalone/.next/static folders manually, after which server.js file will serve these automatically.

Benefits:

• Smaller file size: The standalone folder will be much smaller than the regular Next.js build, which can improve performance and reduce bandwidth usage.
• Faster deployments: Deploying a standalone Next.js app is faster than deploying a regular Next.js app, because there are fewer files to transfer.

Issues:

• Not all features are supported: The output:standalone option is still under development, so not all features of Next.js are supported. For example, you cannot use the next export command to create a static version of your application.
• Requires manual setup: The output:standalone option is not enabled by default, so you must manually add it to your next.config.js file.

[karlhorky]

@ProchaLu ok thanks - however, what I meant to ask was what the concrete difference would be for our apps:

• If we adopt this, what is the difference and changes for our own internal Next.js apps?
• If we adopt this, what is the difference and changes for student Next.js apps?
• make sure that you also review the things that are required for output: 'standalone' eg. the "for that i had to find where to copy the public and .next/static folders to have them be served to the public" part of this comment, which uses the commands rsync -a .next/static/ .next/standalone/.next/static and cp .env.local .next/standalone/.env.local

---

Also, I think that the original change to ./node_modules/.bin/next start was not done correctly:

in 5085c17 I updated the start script command to ./node_modules/.bin/next start.

I don't think this commit was done correctly - it's not about changing next start to ./node_modules/.bin/next start

Tim's message above says "change pnpm start to ./node_modules/.bin/next start" - so that would be a change in the Dockerfile - see the change that I did here:

• upleveled/security-vulnerability-examples-next-js-postgres@6efa6ba

• Fix the Spring example repo c223d74 and ec9867b and fcec1e9