Skip to content

feat: watch the folders a check takes its files from - #334

Merged
alexander-akait merged 1 commit into
mainfrom
feat/watch-where-a-check-looks
Sep 13, 2026
Merged

alexander-akait merged 1 commit into
mainfrom
feat/watch-where-a-check-looks

Conversation

@alexander-akait

Copy link
Copy Markdown
Member

Summary

A file webpack never builds has no watcher of its own until it exists, so adding one changed nothing until something else did — #330 watches the files a check read, and a file that is not there yet is not one of them. The folders a check globs, and the ones a tsconfig.json include covers, now go to webpack as contextDependencies, and the paths an import resolved to nothing through as missingDependencies, so writing the file an import names rebuilds and clears the error. No watcher of our own: this is the same API require.context and webpack's resolver use.

Webpack rebuilds on a change anywhere under a folder it watches, so a folder is watched only when the whole of it can be. Two rules, both measured:

  • It must not hold what the build writes. With output.path under a watched folder, one edit produced 3 builds instead of 2 — every build's own output is the next build's trigger.
  • It must not hold what the check leaves out. Watching a project root with node_modules in it cost +85 MB RSS, against +12 MB with node_modules ignored and +1 MB for a src folder.

So typescript gets this from its tsconfig.json — its include roots are watched whatever files says, which is what fork-ts-checker does — and a glob check gets it when files points at your sources rather than at the project root. Rebuild time and RSS on a 300-file project are unchanged (typescript 49 → 52 ms, 258 → 259 MB, both within the run-to-run spread).

What kind of change does this PR introduce?

feat

Did you add tests for your changes?

Yes — test/stylelint/unbuilt.test.js (a file appearing with nothing else changing), test/typescript/watch.test.js (a file include covers appearing, and the path an unresolved import is watched through), and test/stylelint/directories.test.js for the rules above (watched, output inside, excluded child, folder that is not there).

Does this PR introduce a breaking change?

No.

If relevant, what needs to be documented once your changes are merged or what have you already documented?

Documented in README.md under files.

Use of AI

Claude Code wrote the change, the tests and this description, and ran the measurements above; I reviewed all of it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy


Generated by Claude Code

A file webpack never builds has no watcher of its own until it exists, so
adding one changed nothing until something else did. The folders a check
globs, and the ones a `tsconfig.json` `include` covers, are now handed to
webpack as context dependencies, and the paths an import resolved to
nothing through as missing ones — so creating the file the import names
rebuilds and clears the error.

Webpack rebuilds on a change anywhere under a folder it watches, so a
folder is only watched when the whole of it can be: one holding
`output.path` turns every build's own output into another build, and one
holding what the check excludes would watch `node_modules`. Measured, a
folder holding the output costs a third build for every edit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GzZci4NQeiqwdrVfd7dGXy
@alexander-akait
alexander-akait merged commit 5508d21 into main Sep 13, 2026
13 checks passed
@alexander-akait
alexander-akait deleted the feat/watch-where-a-check-looks branch September 13, 2026 20:02
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.

1 participant