Frames v2: name a Frame after its source folder - #32795
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 2 Skipped Deployments
|
|
r? @flvndvd First PR for the rename change |
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
cc-verify: violations found!
- frame-name-is-the-source-folder: Manifest naming and rename drift
- frame-name-is-one-path-segment: Name limits bypassed
Findings and notifications outside the PR diff:
Source: front/lib/resources/file_resource.ts:1155
Pre-existing setActiveFramePublication violates the new frame-name-is-the-source-folder contract on getFrameV2NameFromMountFilePath (front/lib/api/frames/frame_name.ts): activation still passes descriptor.value.manifest.name into this write. Publishing a Frame registered from folder Health with manifest name Status overwrites its name to Status, undoing the new folder projection.
Source: front/types/api/frame_manifest.ts:74
The pre-existing required name field conflicts with the new frame-name-is-the-source-folder contract on getFrameV2NameFromMountFilePath (front/lib/api/frames/frame_name.ts), which forbids names in manifests. Registration and publication reject otherwise valid nameless manifests, making packages that follow the contract unusable.
Source: front/lib/api/projects/context.ts:722
The pre-existing Pod-folder rename path violates the new frame-name-is-the-source-folder contract on getFrameV2NameFromMountFilePath (front/lib/api/frames/frame_name.ts): renameMountFile changes mountFilePath without refreshing frameName. Renaming a registered Frame's source folder therefore leaves its displayed and shared name at the old folder name.
| { | ||
| status: "ready", | ||
| ...(needsName | ||
| ? { useCaseMetadata: { ...this.useCaseMetadata, frameName } } |
There was a problem hiding this comment.
frame-name-is-one-path-segment on validateFrameV2Name (front/lib/api/frames/frame_name.ts) limits Frame names to 128 characters, but registration persists the folder basename here without validation. An otherwise valid manifest under a 129-character folder passes registration and stores an overlength frameName; the new validator is never called.
| useCaseMetadata: destUseCaseMetadata ?? null, | ||
| useCaseMetadata: | ||
| destUseCaseMetadata && frameName | ||
| ? { ...destUseCaseMetadata, frameName } |
There was a problem hiding this comment.
updateMount bypasses frame-name-is-one-path-segment on validateFrameV2Name (front/lib/api/frames/frame_name.ts): moveFrameV2Source accepts a 129-character destination folder, and this assignment persists that basename unchanged. A previously valid Frame can therefore be renamed beyond the 128-character limit without rejection.
c745947 to
89ff507
Compare
davidebbo
changed the title
A Frame's file is its manifest, so its display name has to come from somewhere else. It now comes from the folder holding that manifest, derived at every point of use rather than stored: the file explorer already labelled Frames this way, while getFileDisplayName, Poke and the share page read a copy in useCaseMetadata.frameName that publish refreshed. The two disagreed whenever the manifest name and the folder differed. Deriving means the name cannot drift from the folder, and it follows a Frame that moves without anything having to refresh it.
89ff507 to
691a386
Compare
2 participants
First of five PRs making the source folder the single definition of a Frames v2 name.
A Frame's file is its manifest, so
fileNameis alwaysmanifest.jsonand the display name has to come from somewhere else. Today it comes from two places that can disagree: the file explorer labels a Frame with its source folder, whilegetFileDisplayName, Poke and the share page readuseCaseMetadata.frameName, a copy ofmanifest.namethat only publish refreshes.This derives the name from the folder holding the manifest, at every point of use, and stores nothing. Deriving is what makes the two views agree by construction: the name cannot drift from the folder, and it follows a Frame that moves without anything having to refresh it.
getFileDisplayNamenow readsmountFilePathinstead of the stored copy — four of its five callers already pass aFileResource, and the fifth (PodFrameSheet) is handed the Frame's path as a prop.Contracts: adds
frame-name-is-the-source-folderandframe-name-is-one-path-segment.