can we not use semiver which is already installed?

can do but it can't handle satisfies strings, only individual comparisons, so configuration would have to be a bit more wordy

does something like this work, and then semiver can be used:

    upgradeRequired: [
       { from: "15.1.0", to: "15.5.20", upgradeTo: "15.5.21" },
       { from: "16.0.0", to: "16.2.10", upgradeTo: "16.2.11" }
    ]

given the intent of this comment, should we fallback to force installing if someone is on a version of nextjs that we can't upgrade for them? this way they'll still have all the cloudflare config files etc. and we can tell them to sort out the framework version later

For next 14 and 15.0.x?

can do, but I think that will require a bit of a refactor as currently anything below minimumVersion is blocked from proceeding. and I think it might require a change in opennext as well to more clearly warn people that they shouldn't deploy that old version. at the moment because of force-install, wrangler deploy autoconfigures the old unsupported version and then happily deploys it 😅

I feel like an alternative might be a custom error message when next 14 is detected which tells people how to use the next codemod to upgrade. then, they upgrade first and wrangler deploy all in one go. don't think this is too difficult to add - just involves overriding the global error in frameworks/next.ts 🙂

🟡 Framework version update can be applied to the wrong directory when the project is not the current directory

The Next.js update is installed in whatever directory the command happens to be running in (installPackages at packages/autoconfig/src/frameworks/next.ts:18) instead of the detected project directory, so when the two differ the project is left unchanged and setup aborts with a "update it manually" error.
Impact: Users who run setup from outside their project folder get a failed setup and an unrelated directory's dependencies modified.

In packages/autoconfig/src/frameworks/next.ts, upgradeFrameworkVersion calls installPackages, which (see packages/cli/packages.ts) runs the package manager in process.cwd() and rewrites process.cwd()/package.json for npm. All other autoconfig operations operate on autoConfigDetails.projectPath, which defaults to process.cwd() but can be passed explicitly by callers (packages/autoconfig/src/details/index.ts). If projectPath differs from the process cwd, the Next.js upgrade is applied to the wrong directory, and the post-upgrade re-validation in packages/autoconfig/src/run.ts then throws an 'update it manually' error. Consider threading projectPath into FrameworkVersionUpgradeOptions and having the install helper accept/forward a cwd so the upgrade targets the same directory as the rest of the flow.

Was this helpful? React with 👍 or 👎 to provide feedback.

Think this is how it's done in all the other framework files – they use don't use projectPath? Might be a separate issue