Skip to content

fix(#112): rewrite file import paths on Explorer rename (+ recovery) - #286

Open
projectcarbonfiber wants to merge 1 commit into
flydelabs:mainfrom
projectcarbonfiber:fix/112-import-rewrite-v2
Open

projectcarbonfiber wants to merge 1 commit into
flydelabs:mainfrom
projectcarbonfiber:fix/112-import-rewrite-v2

Conversation

@projectcarbonfiber

Copy link
Copy Markdown

Fixes #112
/claim #112

Summary

When a .flyde (or code) file that is imported via source: { type: file } is moved in the VS Code Explorer, the importer’s stored relative path went stale and resolution failed (join(flowDir, stored)).

This PR keeps imports working with a dual path:

  1. Primary (Explorer renames): onWillRenameFiles + WorkspaceEdit rewrites only the data scalars of source: { type: file } entries (including nested inline visuals). Pure path math lives in @flyde/loader (getReferenceEditsForRename) so the VS Code adapter stays thin. Edits apply at the old URI before the rename, which plays well with dirty buffers / undo.
  2. Fallback (external / already-stale paths): if the stored path no longer exists at resolve time, recoverMovedFileSource searches the project for the same basename (skipping node_modules / .git / build dirs) and prefers the best path-suffix match.

Package and custom sources are left untouched. Absolute refs, Windows paths, batch/folder renames, and most-specific overlapping maps are covered by hermetic tests.

Acceptance criteria

  • Moving an imported producer (.flyde / .flyde.ts) updates importers’ relative paths
  • Moving a consumer rebases its remaining relative imports
  • Folder / batch renames and most-specific overlapping maps work
  • Nested inline visual source.file entries update
  • Package / custom sources unchanged
  • Dirty-buffer-friendly (onWillRenameFiles + open document text)
  • Stale paths after an out-of-IDE move can still resolve via recovery

Test plan / results

Loader (hermetic), run from loader/:

npx mocha 'src/serdes/rename-references.spec.ts' \
  'src/resolver/server/recoverMovedFileSource.spec.ts' \
  --require ts-node/register --no-timeout

Result: 26 passing (21 rename-reference cases + 5 recovery cases), covering producer/consumer/folder/batch/prefix-safety/simultaneous/most-specific/package-skip/inline/CRLF/aliases/absolute/Windows/cross-drive/invalid YAML/block scalars/anchors + recovery happy/moved/collision/null/node_modules skip.

VS Code contract suite added at vscode/src/test/suite/renameReferences.test.ts (unsaved docs, consumer rebase, malformed skip, authority filter, mid-scan version bump, waitUntil registration). Full extension host run not executed in this environment (pre-existing @flyde/editor build deps); logic under test is the same pure helper covered above.

Notes

Several open PRs already explore Explorer rewrite; this submission focuses on a clean loader-owned rewrite API plus an explicit recovery fallback for moves that never went through VS Code. Happy to adjust scope if maintainers prefer rewrite-only.

Keep source: { type: file } paths valid when .flyde (or code) files move
in the VS Code explorer via onWillRenameFiles + scalar-only YAML edits in
@flyde/loader. Also recover stale paths at resolve time when a file was
moved outside the IDE.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Broken imports after moving files

1 participant