feat: serverurl not required#4
Closed
DanRibbens wants to merge 2 commits intomasterfrom
Closed
Conversation
DanRibbens
force-pushed
the
feature/serverurl-not-required
branch
2 times, most recently
from
5d0f1a2 to
c201a8d
Compare
… examples where not needed
DanRibbens
changed the title
Member
|
Is this complete? It doesn't appear to be working for me. If I remove |
Contributor
Author
|
Moved to new branch, had some merge conflicts and issues with rebase while trying to be more clean. |
denolfe
added a commit
that referenced
this pull request
Oct 7, 2023
jacobsfletch
added a commit
to jacobsfletch/payload
that referenced
this pull request
Oct 15, 2023
denolfe
pushed a commit
that referenced
this pull request
Oct 24, 2023
Fix Google Cloud Storage install instruction
DanRibbens
pushed a commit
that referenced
this pull request
Nov 25, 2024
…ng in `validateQueryPaths` (#9299) ### What? Improves querying performance of the Local API, reduces copying overhead ### How? Adds `flattenedFields` property for sanitized collection/global config which contains fields in database schema structure. For example, It removes rows / collapsible / unnamed tabs and merges them to the parent `fields`, ignores UI fields, named tabs are added as `type: 'tab'`. This simplifies code in places like Drizzle `transform/traverseFields`. Also, now we can avoid calling `flattenTopLevelFields` which adds some overhead and use `collection.flattenedFields` / `field.flattenedFields`. By refactoring `configToJSONSchema.ts` with `flattenedFields` it also 1. Fixes #9467 2. Fixes types for UI fields were generated for `select` Removes this deep copying for each `where` query constraint https://github.com/payloadcms/payload/blob/58ac784425b411fc28c91dbb3e7df06cc26b6320/packages/payload/src/database/queryValidation/validateQueryPaths.ts#L69-L73 which potentially can add overhead if you have a large collection/global config UPD: The overhead is even much more than in the benchmark below if you have Lexical with blocks. Benchmark in `relationships/int.spec.ts`: ```ts const now = Date.now() for (let i = 0; i < 10; i++) { const now = Date.now() for (let i = 0; i < 300; i++) { const query = await payload.find({ collection: 'chained', where: { 'relation.relation.name': { equals: 'third', }, and: [ { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, ], }, }) } payload.logger.info(`#${i + 1} ${Date.now() - now}`) } payload.logger.info(`Total ${Date.now() - now}`) ``` Before: ``` [02:11:48] INFO: #1 3682 [02:11:50] INFO: #2 2199 [02:11:54] INFO: #3 3483 [02:11:56] INFO: #4 2516 [02:11:59] INFO: #5 2467 [02:12:01] INFO: #6 1987 [02:12:03] INFO: #7 1986 [02:12:05] INFO: #8 2375 [02:12:07] INFO: #9 2040 [02:12:09] INFO: #10 1920 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (24667ms) [02:12:09] INFO: Total 24657 ``` After: ``` [02:12:36] INFO: #1 2113 [02:12:38] INFO: #2 1854 [02:12:40] INFO: #3 1700 [02:12:42] INFO: #4 1797 [02:12:44] INFO: #5 2121 [02:12:46] INFO: #6 1774 [02:12:47] INFO: #7 1670 [02:12:49] INFO: #8 1610 [02:12:50] INFO: #9 1596 [02:12:52] INFO: #10 1576 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (17828ms) [02:12:52] INFO: Total 17818 ```
jacobsfletch
pushed a commit
that referenced
this pull request
Nov 25, 2024
…ng in `validateQueryPaths` (#9299) ### What? Improves querying performance of the Local API, reduces copying overhead ### How? Adds `flattenedFields` property for sanitized collection/global config which contains fields in database schema structure. For example, It removes rows / collapsible / unnamed tabs and merges them to the parent `fields`, ignores UI fields, named tabs are added as `type: 'tab'`. This simplifies code in places like Drizzle `transform/traverseFields`. Also, now we can avoid calling `flattenTopLevelFields` which adds some overhead and use `collection.flattenedFields` / `field.flattenedFields`. By refactoring `configToJSONSchema.ts` with `flattenedFields` it also 1. Fixes #9467 2. Fixes types for UI fields were generated for `select` Removes this deep copying for each `where` query constraint https://github.com/payloadcms/payload/blob/58ac784425b411fc28c91dbb3e7df06cc26b6320/packages/payload/src/database/queryValidation/validateQueryPaths.ts#L69-L73 which potentially can add overhead if you have a large collection/global config UPD: The overhead is even much more than in the benchmark below if you have Lexical with blocks. Benchmark in `relationships/int.spec.ts`: ```ts const now = Date.now() for (let i = 0; i < 10; i++) { const now = Date.now() for (let i = 0; i < 300; i++) { const query = await payload.find({ collection: 'chained', where: { 'relation.relation.name': { equals: 'third', }, and: [ { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, ], }, }) } payload.logger.info(`#${i + 1} ${Date.now() - now}`) } payload.logger.info(`Total ${Date.now() - now}`) ``` Before: ``` [02:11:48] INFO: #1 3682 [02:11:50] INFO: #2 2199 [02:11:54] INFO: #3 3483 [02:11:56] INFO: #4 2516 [02:11:59] INFO: #5 2467 [02:12:01] INFO: #6 1987 [02:12:03] INFO: #7 1986 [02:12:05] INFO: #8 2375 [02:12:07] INFO: #9 2040 [02:12:09] INFO: #10 1920 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (24667ms) [02:12:09] INFO: Total 24657 ``` After: ``` [02:12:36] INFO: #1 2113 [02:12:38] INFO: #2 1854 [02:12:40] INFO: #3 1700 [02:12:42] INFO: #4 1797 [02:12:44] INFO: #5 2121 [02:12:46] INFO: #6 1774 [02:12:47] INFO: #7 1670 [02:12:49] INFO: #8 1610 [02:12:50] INFO: #9 1596 [02:12:52] INFO: #10 1576 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (17828ms) [02:12:52] INFO: Total 17818 ```
kendelljoseph
pushed a commit
that referenced
this pull request
Feb 21, 2025
…ng in `validateQueryPaths` (#9299) ### What? Improves querying performance of the Local API, reduces copying overhead ### How? Adds `flattenedFields` property for sanitized collection/global config which contains fields in database schema structure. For example, It removes rows / collapsible / unnamed tabs and merges them to the parent `fields`, ignores UI fields, named tabs are added as `type: 'tab'`. This simplifies code in places like Drizzle `transform/traverseFields`. Also, now we can avoid calling `flattenTopLevelFields` which adds some overhead and use `collection.flattenedFields` / `field.flattenedFields`. By refactoring `configToJSONSchema.ts` with `flattenedFields` it also 1. Fixes #9467 2. Fixes types for UI fields were generated for `select` Removes this deep copying for each `where` query constraint https://github.com/payloadcms/payload/blob/58ac784425b411fc28c91dbb3e7df06cc26b6320/packages/payload/src/database/queryValidation/validateQueryPaths.ts#L69-L73 which potentially can add overhead if you have a large collection/global config UPD: The overhead is even much more than in the benchmark below if you have Lexical with blocks. Benchmark in `relationships/int.spec.ts`: ```ts const now = Date.now() for (let i = 0; i < 10; i++) { const now = Date.now() for (let i = 0; i < 300; i++) { const query = await payload.find({ collection: 'chained', where: { 'relation.relation.name': { equals: 'third', }, and: [ { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, { 'relation.relation.name': { equals: 'third', }, }, ], }, }) } payload.logger.info(`#${i + 1} ${Date.now() - now}`) } payload.logger.info(`Total ${Date.now() - now}`) ``` Before: ``` [02:11:48] INFO: #1 3682 [02:11:50] INFO: #2 2199 [02:11:54] INFO: #3 3483 [02:11:56] INFO: #4 2516 [02:11:59] INFO: #5 2467 [02:12:01] INFO: #6 1987 [02:12:03] INFO: #7 1986 [02:12:05] INFO: #8 2375 [02:12:07] INFO: #9 2040 [02:12:09] INFO: #10 1920 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (24667ms) [02:12:09] INFO: Total 24657 ``` After: ``` [02:12:36] INFO: #1 2113 [02:12:38] INFO: #2 1854 [02:12:40] INFO: #3 1700 [02:12:42] INFO: #4 1797 [02:12:44] INFO: #5 2121 [02:12:46] INFO: #6 1774 [02:12:47] INFO: #7 1670 [02:12:49] INFO: #8 1610 [02:12:50] INFO: #9 1596 [02:12:52] INFO: #10 1576 [PASS] Relationships > Querying > Nested Querying > should allow querying two levels deep (17828ms) [02:12:52] INFO: Total 17818 ```
GermanJablo
added a commit
that referenced
this pull request
Jun 9, 2025
Important: An intentional effort is being made during migration to not modify runtime behavior. This implies that there will be several assertions, non-null assertions, and @ts-expect-error. This philosophy applies only to migrating old code to TypeScript strict, not to writing new code. For a more detailed justification for this reasoning, see #11840 (comment). In this PR, instead of following the approach of migrating a subset of files, I'm migrating all files by disabling specific rules. The first commits are named after the rule being disabled. With this PR, the migration of the payload package is complete 🚀
elliott-w
pushed a commit
to elliott-w/payload
that referenced
this pull request
Jun 12, 2025
…4 (payloadcms#12733) Important: An intentional effort is being made during migration to not modify runtime behavior. This implies that there will be several assertions, non-null assertions, and @ts-expect-error. This philosophy applies only to migrating old code to TypeScript strict, not to writing new code. For a more detailed justification for this reasoning, see payloadcms#11840 (comment). In this PR, instead of following the approach of migrating a subset of files, I'm migrating all files by disabling specific rules. The first commits are named after the rule being disabled. With this PR, the migration of the payload package is complete 🚀
r1tsuu
added a commit
that referenced
this pull request
Apr 21, 2026
Run #4 shipped a dataloader load() hook, but the access-control TanStack suite stayed 0/2 with the same SyntaxError: ...dataloader/index.js does not provide an export named 'default' because nothing intercepted the original import. Two issues were stacked: 1. In CI, payload is installed from packed tarballs into test/node_modules. When payload/dist/collections/dataloader.js does `import 'dataloader'`, Vite resolves it via test/node_modules/.pnpm/dataloader@2.2.3/... — a different physical path than the pre-bundled entry (which resolved via the workspace packages/payload → root node_modules/.pnpm/...). Vite's resolver sees the mismatch and serves the raw CJS instead of the pre-bundled ESM wrapper. 2. Vite then appends ?v=<hash> to the served URL, so the existing load() hook's `id.endsWith('/index.js')` check never fires against the queried path. Mirror the deepmerge/pluralize/ajv pattern: add a transform() hook that rewrites `from 'dataloader'` inside payload/dist/collections/dataloader.js directly to /node_modules/.vite/deps/payload___dataloader.js. That is the primary fix and bypasses any resolution ambiguity. Also make the load() hook query-safe (strip ?v=<hash> before the endsWith check) as a defensive fallback for any other importer. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
r1tsuu
added a commit
that referenced
this pull request
Apr 21, 2026
…otstrap Run #4's Map→object fix for versionViewData.clientSchemaMap landed but the versions diff-view shard stayed 0/40. The actual blocker was a separate non-serializable value in the payload — RegExp literals from rich-text feature markdownTransformers (e.g. UPLOAD_PLACEHOLDER_REGEX, /!\[([^\]:]+):([^\]]+)\]\(\)/). toSerializable previously preserved RegExp unchanged. seroval then serializes the regex into the SSR bootstrap script, but with doubled backslashes in source (emits `/!\\[.../` instead of `/!\[.../`). That is syntactically invalid JS regex ("Unmatched ')'"), so the script that populates `window.$_TSR` throws mid-stream. TanStack hydration then fails with "Invariant: Expected to find bootstrap data on window.$_TSR", the client re-renders the tree empty, and the diff wrapper never reaches the DOM — hence every test in `versions/e2e.spec.ts › Versions diff view` timed out waiting for `.render-field-diffs`. Next.js doesn't hit this because its server→client transport is JSON, which silently drops RegExp. Strip RegExp here to match that behavior. Rich-text transformer regexes are server-only (markdown import/export) and aren't referenced by buildVersionFields or any client renderer, so the loss is harmless. Verified locally against test/versions/config.ts: before, the page stuck at the Invariant error with an empty client tree; after, the bootstrap parses, hydration completes, and .render-field-diffs renders through SSR. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
2 participants
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.
No description provided.