First-Party Source Resolution
All first-party monorepo development and validation flows must resolve local @lapis-notes/* package imports from source under each dependency’s src/ tree. Resolving those imports through package dist/ outputs during development is forbidden.
Rule
- Apply this rule to every Vite-driven local flow in the repo, including app hosts, package-local
vitedev sessions, Vitest or Vite-powered validation, and any other development-time module graph evaluation. - Apply the same source-first expectation to package-local TypeScript and Svelte diagnostics. Checks that do not load Vite must provide equivalent
tsconfigpath mappings for any first-party self-imports they validate. - Apply the same source-first expectation to other repo-local check tools that compile or typecheck first-party imports, including TypeDoc and package-local custom tsconfig files such as
typedoc.tsconfig.jsonortsconfig.check.json. - Resolve both root imports such as
@lapis-notes/searchand subpath imports such as@lapis-notes/api/iconor@lapis-notes/ui/buttonto source. - Apply the same rule to first-party stylesheet imports. CSS or SCSS
@importspecifiers such as@lapis-notes/ui/theme.cssor pluginapp.cssentries must resolve into dependencysrc/trees during local development instead of packageddist/CSS artifacts. - Apply the same rule to self-imports. A package importing its own published name during development must still resolve back into its own
src/tree instead of its packageddist/exports. - Do not add or preserve package-specific
dist/fallbacks in dev because a source file currently fails to compile. Fix the underlying source or tooling issue instead. tsconfig.pack.jsonis forsvelte-packageprepack only. Do not point validation, TypeDoc, or other check tools at pack tsconfigs; those configs intentionally omit cross-package source paths.- Published package manifests may continue to export
dist/artifacts for packaging and external consumption, but repo-local development resolution must override those exports back to source.
Enforcement
- The repo-root
pnpm check:source-resolutioncommand is the executable enforcement point for this contract. - That guard loads each package’s Vite config in development mode, resolves real first-party
@lapis-notes/*imports from package source files and stylesheet@importsources, and fails if any resolution lands outside the dependency’ssrc/tree. - The same guard resolves explicit subpath entrypoints (for example
@lapis-notes/ui/table-dnd/sensors) through workspace, desktop-electron, and web app-host Vite configs using real cross-package importers, because those hosts keep separate dev resolver registries from package-local Vite configs. - The same command runs
scripts/check-first-party-tsconfig-resolution.mjs, which resolves real first-party imports through each package’s Svelte/TypeScripttsconfigpathsmappings without relying on packageddist/outputs. It also auto-discoverspackage.jsonexport subpaths that wildcardpathspatterns cannot reach and requires them to stay listed infirstPartySourceExplicitSubpathEntrypoints. - The same command runs
scripts/check-first-party-vitest-resolution.mjs, which loads each package’svitest.configorvite.configin test mode and resolves first-party imports from Vitest test files (includingvi.mock("@lapis-notes/...")targets) to dependencysrc/trees instead of packageddist/outputs. - The same command runs
scripts/sync-first-party-source-tsconfig-paths.mjs --checkso packagetsconfig.jsonandtsconfig.app.jsonfiles keep first-partypathsmappings in sync with the Vite source-resolution registry for Svelte and TypeScript diagnostics. When that sync script writes updates, it also runs Prettier on the touched tsconfig files so packagecheck:formatstays aligned without a separate manualpnpm fmtpass. - The same command validates plugin
vite.styles.config.tsbuild configs that@referenceworkspaceapp.csscan still resolve shared UI CSS entrypoints from source (for example@lapis-notes/ui/theme.cssimported by the workspace stylesheet). - The same command rejects
tsconfig.pack.jsonreferences outsideprepack/buildscripts so check and docs tooling cannot accidentally depend on packageddist/outputs. - Agents and contributors must treat failures from that guard as contract violations, not optional warnings.