Repository navigation
refactor!: consolidate request creation APIs - #18287
Merged
Merged
Conversation
Contributor
📦 esbuild Bundle Analysis for payloadThis analysis was generated by esbuild-bundle-analyzer. 🤖
Largest pathsThese visualization shows top 20 largest paths in the bundle.Meta file: packages/next/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_index.json, Out file: esbuild/index.js
Meta file: packages/payload/meta_shared.json, Out file: esbuild/exports/shared.js
Meta file: packages/richtext-lexical/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_client.json, Out file: esbuild/exports/client_optimized/index.js
Meta file: packages/ui/meta_shared.json, Out file: esbuild/exports/shared_optimized/index.js
DetailsNext to the size is how much the size has increased or decreased compared with the base branch of this PR.
|
jacobsfletch
force-pushed
the
refactor/payload-req-creation
branch
from
September 24, 2026 15:30
9e94248 to
daa1f1a
Compare
jacobsfletch
marked this pull request as ready for review
September 25, 2026 01:22
jacobsfletch
requested review from
AlessioGr,
DanRibbens,
JarrodMFlesch and
denolfe
as code owners
September 25, 2026 01:22
AlessioGr
approved these changes
Sep 25, 2026
Ducksss
added a commit
to Ducksss/payload-components
that referenced
this pull request
Oct 4, 2026
…resh smoke create-payload-app 4 renamed --version to --payload-version. Its argument parser is permissive, so the old flag was silently dropped and a smoke pinned to 4.0.0-canary.37 scaffolded whatever the `canary` dist-tag resolved to. Pass the flag each major reads, and both for a dist-tag. create-payload-app 4 also downloads its template from the payloadcms/payload main branch instead of the release it installs. Main had already renamed createLocalReq (payloadcms/payload#18287, after canary.37 shipped), so the pinned scaffold failed tsc in the template's own seed route. Pin a v4 template to the release tag with --branch when that tag exists; v3 keeps its CLI's 3.x branch and needs no network check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Ducksss
added a commit
to Ducksss/payload-components
that referenced
this pull request
Oct 4, 2026
* cli(feat): accept Payload 4 projects alongside Payload 3 Payload 4 is in canary (4.0.0-canary.37) and every install into a v4 project was refused. Allow major 4 in both support-matrix targets and in every manifest (payloadMajors [3, 4], payload peer "^3.0.0 || ^4.0.0-0"), the component template, and the `new` scaffold. Widening the ranges alone was not enough: semver.intersects without includePrerelease tests each comparator on its own, so "<5.0.0-0" rejects 4.0.0-canary.37 and a pinned prerelease never intersects "^4.0.0-0". The "-0" bounds on every required range keep prereleases inside their major. detectProject now names an unsupported Payload or Next.js major instead of reporting "Unsupported project shape", which is what a v4 project got. The base Pages collection gains an explicit readVersions (signed-in only). Payload 4 inherits read access for versions (payloadcms/payload#17634), so visitors could list every previously published version. Payload 3 already requires a user here, so this is a no-op on v3. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * cli(fix): scaffold the pinned Payload 4 version and template in the fresh smoke create-payload-app 4 renamed --version to --payload-version. Its argument parser is permissive, so the old flag was silently dropped and a smoke pinned to 4.0.0-canary.37 scaffolded whatever the `canary` dist-tag resolved to. Pass the flag each major reads, and both for a dist-tag. create-payload-app 4 also downloads its template from the payloadcms/payload main branch instead of the release it installs. Main had already renamed createLocalReq (payloadcms/payload#18287, after canary.37 shipped), so the pinned scaffold failed tsc in the template's own seed route. Pin a v4 template to the release tag with --branch when that tag exists; v3 keeps its CLI's 3.x branch and needs no network check. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * ci(feat): add a non-blocking nightly Payload canary smoke The nightly fresh smoke follows Payload `latest`, so nothing exercised the next major before it ships. Run the same bare and website scenarios against `npm view payload@canary version` on Node.js 24 (Payload 4 requires 24.15+), schedule-only and with continue-on-error, outside pr-gate. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * cli(fix): widen related-posts to Payload 4 and hold manifests to the support matrix related-posts (#600) landed declaring Payload 3 only, so once Payload 4 is allowed it would be the one component refusing v4 projects. Give it the same supports and peer range as every other manifest; manifest-only, so the versioned-source contract needs no version bump. payload-components-support-matrix.int.spec.ts makes this class of drift fail: every manifest, the component template and the `new` scaffold must declare exactly the Payload and Next.js majors their targets allow, with peer ranges that cover each major's stable line and the newest Payload major's prereleases. A v3-only fixture keeps the guard from passing vacuously. buildManifest is exported so the scaffold's output can be checked directly. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
🚀 This is included in version v4.0.0-canary.38 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow up to #17690
Consolidates
PayloadRequestcreation around a canonicalcreatePayloadRequestfunction.Payload currently exposes three overlapping paths for constructing a
PayloadRequest:createLocalReqfor local operationscreatePayloadRequestto convert incomingWebRequestobjectsinitReqfor admin renderingcreatePayloadRequestandinitRequltimately delegate tocreateLocalReq, but their names obscure that relationship.createPayloadRequestsounds like the general primitive despite being specific to Web requests, whileinitReqdoes not communicate that it prepares the complete admin context in addition to creating the req.The new names describe each functions purpose much more clearly to remove any ambiguity or confusion.
Breaking Changes
Consumers that directly import request helpers, internal admin context types, or provide a custom Root layout adapter must migrate the renamed APIs.
createLocalReqcreatePayloadRequestcreatePayloadRequestcreatePayloadRequestFromWebRequestinitReqinitAdminContextTypes have also been renamed to match:
InitReqArgsInitAdminContextArgsInitReqResultAdminContextInitReqCacheAdminContextCacheInitReqPartialResultPartialAdminContextLocal request creation now accepts
payloadin the options object:Web request conversion uses its role-specific name:
Custom Root layout adapters must rename their injected admin context callback:
The migration guide documents options that require manual handling, including complex expressions and private imports of
CreateLocalReqOptions.Codemod
To migrate automatically, there's a codemod for this change available by running: