Add migrate command for initializing open-next for existing Next.js projects

[dario-piotrowicz]

Fixes https://jira.cfdata.org/browse/DEVX-2383

---

Docs PR: opennextjs/docs#205

---

This PR addes a new migrate CLI command that adds the OpenNext adapter to standard Next.js projects (this basically automates the steps in https://opennext.js.org/cloudflare/get-started).

---

You can manually test this command by running:

npm create next-app  my-next-app

to create a new Next.js project, cd into the project:

cd my-next-app

install a compatible version of Next.js:

npm i next@16.0.x

and then run the init command:

npx https://pkg.pr.new/@opennextjs/cloudflare@1083 migrate

You should see something like the following:

---

Thanks to @2u841r to spearheading this effort 🫶

[changeset-bot]

🦋 Changeset detected

Latest commit: 608b497

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@opennextjs/cloudflare	Minor

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@opennextjs/cloudflare@1083

commit: 608b497

[dario-piotrowicz]

@vicb right now if an incorrect version of Next.js is used we get this:

probably we should check the version and handle it more gracefully, right?

or shall we even try to bump the version? what do you think?

[vicb]

A lot of nits.

Also I realize that not having a monorepo makes it much harder to discover utils.

Should hopefully be fixed soon

[vicb]

Same comment about moving the detection than for the wrangler config

[dario-piotrowicz]

does this work?

4886b79

[vicb]

It works.

I usually add a "maybe" in the mix if it can return undefined or throw when there is no "maybe"

[vicb]

Also would be nice if the API is consistent for the different files

[dario-piotrowicz]

I usually add a "maybe" in the mix if it can return undefined or throw when there is no "maybe"

The return type make it clear to me so adding a maybe feels unnecessary to me, but I'm happy to add that since it's your preference 👍

Also would be nice if the API is consistent for the different files

I thought the same when implementing the two solutions... but having a return from a function that is never actually used feels ugly/potentially confusing to me, but it's not a huge deal, I'm totally happy to use a consistent API 👍

[vicb]

The return type make it clear to me so adding a maybe feels unnecessary to me, but I'm happy to add that since it's your preference 👍

When you review code on GH, you don't get to see the return type easily

I thought the same when implementing the two solutions... but having a return from a function that is never actually used feels ugly/potentially confusing to me, but it's not a huge deal, I'm totally happy to use a consistent API 👍

I need to double check the code here, I thought it was used

[vicb]

Could you please merge master in this PR instead of rebasing?
I realize that I have been commenting the same thing multiple time because it doesn't show up in the diff view.
GH is a pain here :(