PathMend: Find Broken Paths in Config Files

Find broken paths in your config files after a move or rename - before CI, docker build or npm publish does.

You move scripts/start.sh to tools/start.sh. The editor updates the imports in your code, the tests pass, and you push. Then CI fails, because a string in a config file still says scripts/start.sh:

• the Dockerfile has COPY scripts/start.sh /usr/local/bin/, so the image build fails with COPY failed: file not found in build context
• package.json has "bin": "scripts/start.sh", so the published package is broken
• a workflow has run: bash scripts/start.sh, or working-directory: services/old-name
• CODEOWNERS still lists /scripts/, so reviews stop being requested

Tools that check import paths only look at code. PathMend looks at the config files, where these paths are plain strings that nothing else checks.

Real examples:

• software-mansion/react-native-reanimated#3026 - "Package json main points to non existing file", shipped in a release.
• docker/build-push-action#97 - "What's the Context for COPY?" - a Dockerfile COPY path that does not match the build context.

What it checks

A glob is fine when it matches at least one file. Skipped on purpose: COPY --from=<stage>, URLs and git contexts, anything with $VAR, ${VAR} or ${{ }}, bare package specifiers in extends, paths in a tsconfig that may inherit its baseUrl from a package in extends (or whose baseUrl is itself missing), jobs whose actions/checkout uses a custom path:, and references into build output folders (see pathmend.ignoreReferences; the outDir of your tsconfigs is added automatically, so "main": "build/index.js" is not reported before a build).

Rules

Each diagnostic sits on the exact path string, with source PathMend.

Quick Fix: "Did you mean ...?"

For a missing path, PathMend looks for the closest existing file or folder in the workspace: the same file name in another folder first (the usual "moved it" case), otherwise a close spelling of the name. The fix keeps your style - a leading ./, a leading / in CODEOWNERS and GitLab includes, ${workspaceFolder} in launch.json, a trailing / - and for Dockerfiles only suggests files inside the build context.

Rename and move: update all references

When you rename or move a file or folder in VS Code (Explorer, drag and drop, or a refactoring), PathMend compares with the references it saw before the move and shows:

3 config references still point to src/utils - update all?

• Update all rewrites those strings in the config files and saves them.
• Preview opens the standard refactor preview, so you can review and untick edits.
• Ignore leaves them - they then show up as normal diagnostics.

Only config files inside the workspace are edited. Renames done outside VS Code (for example git mv in a terminal) are not seen as renames; the references simply show up as broken.

Settings

Activity bar and commands

• Activity bar - the PathMend view lists every broken reference, grouped by config file. Each row is labelled with the rule and the exact path string (for example PM003 scripts/start.sh), shows the rule and line next to it, and opens the file on that path when clicked. Rows with a suggestion have an inline Apply suggested path action (the same edit as the "Did you mean ...?" Quick Fix). The badge shows the number of broken references; the title bar has Show broken references and Scan workspace.
• PathMend: Scan workspace - rebuild the file index and check every config file.
• PathMend: Show broken references - pick a broken reference and jump to it.

The status bar shows the number of broken references; click it for the same list. Files created, deleted or moved outside VS Code (for example by git checkout) are picked up when the window regains focus and once a minute, even where the editor's file watcher misses them.

Privacy and safety

• No network, no telemetry, no child processes. PathMend never runs git, docker, node or any other program.
• Only config files are read. They are found with the editor's own file search inside your workspace folders. Referenced files are only checked for existence - their contents are never opened.
• Nothing outside the workspace is touched. A path from a config file is resolved first, and is only checked when it lies inside a workspace folder. Symlinks are followed one step at a time; a link that leads outside the workspace stops the check before anything behind it is touched. Absolute paths, ../ escapes and escaping symlinks are reported as PM010 ("outside the workspace - not checked"). A config file that is itself a symlink to outside the workspace is not read.
• Works in untrusted workspaces, because it only reads config files and checks whether paths exist.
• Edits happen only when you choose a Quick Fix or a rename update, and only in config files inside the workspace.

Limitations

• The YAML reader is line-oriented: block maps and sequences, block scalars, one-line flow lists, quotes, comments. Multi-line flow collections and anchors merged with <<: are not followed.
• The Docker build context is only known when a Compose file points at the Dockerfile. Contexts passed on the command line (docker build -f docker/Dockerfile .) or in docker/build-push-action are not read, so a source is accepted if it exists relative to the Dockerfile folder or any parent folder up to the workspace root. .dockerignore is not applied.
• run: scripts are only recognised in command position (./x.sh, or after bash, sh, python, node and similar). Files created earlier in the same step are reported as missing.
• Glob matching and "did you mean" use an index of up to pathmend.maxIndexedFiles files; in a larger workspace unmatched globs are not reported.
• A rename update is skipped for references inside a config file that was itself moved.
• Out of scope by design: env_file and ${VAR} in Compose files, and script line endings, shebangs and executable bits.

License

MIT - included with the extension.