refactor: project options type shared with build + config init

[james-elicx]

Context

We have what seems to be a pre-options and then options. It would help in the long-term to have a single set of options that we use to stub the project setup and the config creation, especially if we add more CLI options in the future. Therefore, the types are slightly refactored to share the same thing between the creation of the project config and the project setup function.

I don't mind if you want to keep it as is, but I think it would be simpler to have a single object used between the two.

I wanted to move the config creation to before the project setup outside but it currently depends on the build happening in order to generate the config unfortunately for the .next server directory.

Changes

• Shares the same input between the two.
• Renames builderOutput to outputDir and nextApp to sourceDir, as it's the output directory and the source directory.

basically centralises where i need to make a change if i want to add a new cli arg (e.g. #89) and use it in the config, otherwise you need to update multiple types and args normally

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0d3b69d

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[pkg-pr-new]

Open in Stackblitz

pnpm add https://pkg.pr.new/@opennextjs/cloudflare@88

commit: 0d3b69d

[vicb]

Thanks for the PR, I added a few minor comments.

For the next time please do me a favor and split changes in multiple commits. For example the first commit should have been the config refactoring and the second the renaming which would be trivial to review. It would be much faster to review.

[james-elicx]

For the next time please do me a favor and split changes in multiple commits. For example the first commit should have been the config refactoring and the second the renaming which would be trivial to review. It would be much faster to review.

Ah sorry about that, totally fair point - will do in the future.

[vicb]

Thanks!