When a package ships files or bytes, keep them inside the package file. Consumer packages should receive named data or target replies, not random file paths into another package.
A help package ships markdown, a theme package ships images, and a file-preview package ships a small parser. A consumer wants the rendered result. The consumer should not read arbitrary files from the package folder.Package bytes should move with the package. Consumers should use public reads or requests, not private file paths that happen to work today.Traditional app shape
Bitfield shape
Boundary example
Four file situations
Help markdown
Private help path
Prepared help read
Preview HTML
Private preview bundle
Prepared preview surface
Review template
Private template import
Prepared template read
Search index
Private search index
Search through the package target
Consumer rules
What this prevents
React is one adapter that might render the bytes, but React does not define the package file. A web shell, native shell, terminal shell, or future adapter should receive named data from the same package-owned material.
Review checklist
Full before and after
Traditional feature request
“Add a help panel that shows package help and lets the user search it.”Bad implementation
Public package version
Good consumer code
React adapter example
Review check
If consumer code imports../some-package/content/file.md, stop. Package files are package material. Consumers should read a data name or request a target.Next
- Build package-owned bytes: Package-owned file
- Learn package rules: Packages
- Look up boundary fields: Package file