refactor(annotation): use #src/* subpath imports for cross-directory refs#233
Open
contextbotai[bot] wants to merge 1 commit into
Open
refactor(annotation): use #src/* subpath imports for cross-directory refs#233contextbotai[bot] wants to merge 1 commit into
contextbotai[bot] wants to merge 1 commit into
Conversation
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
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.
What & why
The root
AGENTS.mdImports convention states:Every TypeScript workspace complies (
cli,context,harness,instrumentation,server,shared,skills,storage,ui) except@contextbridge/annotation, which had neither the#src/*mapping nor a single subpath import. It reached across directory boundaries with relative..//../../paths — the exact pattern the convention forbids.This was the single most-egregious violation class by frequency and clarity: 20 cross-directory relative imports across 10 files, all in one package, all mechanically fixable with zero behavior change.
Changes
"imports": { "#src/*": "./src/*" }topackages/annotation/package.json, bringing it in line with every other source package...//../../imports to#src/*in:src/demo/DemoStage.tsxsrc/element/ElementAdapter.tssrc/element/mermaid/MermaidBlock.tsxsrc/element/mermaid/mermaidAdapter.tssrc/element/mermaid/mermaidAdapter.test.tssrc/element/useElementTargets.tssrc/testHelpers/appContextDecorator.tsxsrc/testHelpers/createFakeAppContext.tssrc/testHelpers/index.tsxsrc/testHelpers/renderAnnotationHook.tsxSame-directory
./sibling imports were left relative, as the convention explicitly permits.Verification
bun run typecheck(annotation) — passes; TSmoduleResolution: bundlerresolves#src/*via the package.jsonimportsfield, no tsconfigpathsneeded.bun run build(annotation) — passes; Vite 6 resolves#src/*natively. Output is byte-identical to baseline (same 4840 modules transformed, samedist/index.htmlsize), confirming no behavior change.prettier --checkon all changed files — clean.eslint --max-warnings 0on all changed files — clean (import ordering preserved).vitest(browser mode) collects all 12 test files without resolution errors. It could not launch the browser in this sandbox due to a pre-existing Playwright version mismatch (installedchromium-1228,@vitest/browser-playwrightexpects-1217) — an environment issue unrelated to this change; module resolution itself is confirmed working since collection succeeded.Notes for the reviewer / future runs
Other, lower-priority violation classes I noticed but intentionally did not touch (one class per run):
packages/instrumentation/src/node/harnessDiscovery.test.tshand-rolls a localcreateDeferred(new Promisewrapper) instead of importingcreateDeferredfrom@contextbridge/shared/testHelpers, which the testing-patterns rule forbids. Single instance.readFileSync/readdirSync({ withFileTypes: true })sites (skills/src/skills.ts,storage/src/db/loadMigrations.macro.ts,storage/src/paths.ts) could arguably move toBun.file/Bun.Globper the bun-native-apis rule, but that rule explicitly says the syncfsAPIs are "not banned outright," so these are borderline.The remaining
../imports inpackages/websiteare.astro/.mdxasset and component imports on Astro's own toolchain (not the TypeScriptimports-field convention) and are out of scope.