You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Feb 1, 2025. It is now read-only.
After testing of open-next and SST I will be deprecating this package in foreseeable future in favour of SST and Open-Next.
Reasons are as following:
open-next took basic idea I had with this package and build complete support for developing Next,
connection with SST gives developers amazing experience when running and trying things locally - something I'm not planning to include or try to duplicate,
SST supports newer syntaxes and generally better keeps up with Next's changes thank to bigger community,
open-next builds on CDK and allows deployments to non-Edge lambdas, which go hand-in-hand with ideology of mine and this project,
Extra features such as ISR are supported.
Currently only one concern in mind:
Complexity of open-next and possibility to lot of things to brake (mapping of experimental flags, need to pass Next's env flags to build, Sharp bundling and generally using JS for image optimization - Python implementation we use now). However, with vivid community this is something, we can overcome.
One future issue I came by with current package as well as open-next
bundling of node_modules for Lambda's environment. Binary-specific dependencies get's bundled locally on host OS and might not be compatible with Lambda's runtime. This is industry-wide problem solvable by Docker and pipelines, however, not compatible with SST's dev experience.
Cheers!
Jan
The text was updated successfully, but these errors were encountered:
Sad to here that, but the reasons make sence. We currently use your library to build Next.js projects but Open-Next looks promising and evene migration couldn't be so hard.
It's unfortunate to hear about EOL, but the reasons make sense. Currently, we are using your library to build Next.js projects and deploy them to AWS with our custom Terraform configs. However, Open-Next looks promising, and I believe that migrating to it may not be too challenging.
After testing of open-next and SST I will be deprecating this package in foreseeable future in favour of SST and Open-Next.
Reasons are as following:
Currently only one concern in mind:
One future issue I came by with current package as well as open-next
node_modules
for Lambda's environment. Binary-specific dependencies get's bundled locally on host OS and might not be compatible with Lambda's runtime. This is industry-wide problem solvable by Docker and pipelines, however, not compatible with SST's dev experience.Cheers!
Jan
The text was updated successfully, but these errors were encountered: