-
Notifications
You must be signed in to change notification settings - Fork 747
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bump C3's create-next-app to 15.0.3 #7241
Conversation
A wrangler prerelease is available for testing. You can install this latest build in your project with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-wrangler-7241 You can reference the automatically updated head of this PR with: npm install --save-dev https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/prs/7241/npm-package-wrangler-7241 Or you can use npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-wrangler-7241 dev path/to/script.js Additional artifacts:npx https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-create-cloudflare-7241 --no-auto-update npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-kv-asset-handler-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-miniflare-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-pages-shared-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-vitest-pool-workers-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-workers-editor-shared-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-workers-shared-7241 npm install https://prerelease-registry.devprod.cloudflare.dev/workers-sdk/runs/12282270102/npm-package-cloudflare-workflows-shared-7241 Note that these links will no longer work once the GitHub Actions artifact expires.
Please ensure constraints are pinned, and |
75aa685
to
341684a
Compare
🦋 Changeset detectedLatest commit: 8dfcae6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
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 |
Note This PR updates the non-experimental Next.js C3 template, so I think that the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great, thanks @dario-piotrowicz
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so I think that the C3 E2E Tests (experimental) checks (which are failing because of Next.js) can safely be ignored
I don't think it is fair to break the experimental Next.js support by bumping the Next.js dependency.
If we can't separate them to use different versions of Next.js then I think we need to ensure they are both fixed together.
ah yeah for sure! I was under the assumption that the experimental e2e was failing either way I didn't realize the bump was breaking it (but it clearly runs without the bump: example run) it's quite unfortunate that the create-next-app bump effects both templates 😕 😓 |
I think @vicb was working up updating opennextjs? |
I'm looking at the code and I don't think there's a clean way to use different versions of We could have a new Alternatively we could have some very hacky Or yeah just wait for our opennext adapter to support Next 15 😓 |
// we do this because the stable @opennextjs/cloudflare package | ||
// does not yet support Next 15, we should move away from this | ||
// as soon as possible | ||
"https://pkg.pr.new/@opennextjs/cloudflare@experimental", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked at the details but the experimental branch should have an open next config file and a different wrangler.toml.
Should they be updated as part of the PR?
Also loading instrumentation will fall on 15.0.3 if not patched.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah yeah of course, good callout 😓👍
@petebacondarwin what do you think of this temporary workaround for the experimental template issue? |
* The version of the framework cli tool to use. | ||
* If omitted the cli version is taken from src/frameworks/package.json, which is the default/standard behavior. | ||
*/ | ||
frameworkCliVersion?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another option would be to allow frameworkCli
to specify the version (i.e. [email protected]
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach is fine. You could even change it to something to make it clear this is exceptional:
frameworkCliVersion?: string; | |
pinFrameworkCliVersion?: string; |
We use dependabot to keep the CLI versions up to date, which is why they are stored in a package.json. Moving the versions here would mess that up. But in this case we don't want dependabot to do anything with this version since we are explictly pinning it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My proposal is to use either cli
to use the version from the package.json or cli@version
to pin the version as an alternative to using the pinFrameworkCliVersion
property
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I understand. But in doing that it is not clear that this is not the intended normal way to specify the version in cases where we do not need to pin the version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@petebacondarwin I've renamed the field as you suggested 🙂
I've also updated the comment to make the thing a bit clearer
* The version of the framework cli tool to use. | ||
* If omitted the cli version is taken from src/frameworks/package.json, which is the default/standard behavior. | ||
*/ | ||
frameworkCliVersion?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this approach is fine. You could even change it to something to make it clear this is exceptional:
frameworkCliVersion?: string; | |
pinFrameworkCliVersion?: string; |
We use dependabot to keep the CLI versions up to date, which is why they are stored in a package.json. Moving the versions here would mess that up. But in this case we don't want dependabot to do anything with this version since we are explictly pinning it.
This reverts commit d0b9cee.
…create-next-app cli
c36670d
to
3eaa022
Compare
This PR is for updating C3 to create a Next.js 15 app in non-experimental mode
However (see comments below) the bump of create-next-app for non-experimental mode currently applies to both the non-experimental and experimental Next.js templates, forcing us to either make sure that both templates can work with Next.js 15 or that we find a way to have each use a different version of create-next-app