Framework guides
WRNexus components use native HTML semantics and framework component mounts.
Configure and use it
This is the smallest useful starting point. Copy it into the indicated application file or run it from the project root, then adjust the documented values for your product.
bunx wrnexus inspect component Navbar .
bunx wrnexus typecheck .What changes after this
The page depends on public component props, slots, and outputs, so framework upgrades do not depend on private markup.
Mount components
Use the component mount name directly in .wrn views. Props are typed, slots remain server-rendered, and declared outputs reach parent bindings.
Own page composition
Keep application structure in pages and layouts. Use library components for reusable behavior, then add application-specific styles in the owning .wrn file.
Prefer semantic contracts
Choose props, slots, and outputs over selectors that depend on a component's internal markup. This keeps applications compatible with framework upgrades.
Inspect before integrating
Use the CLI component inspector for the exact prop, slot, and output contract, then type-check the finished page.
Verify the result
Type-check the application, inspect the resolved package and styles, and build the production artifact. Test the page at a narrow viewport, with keyboard navigation, and in both color modes before shipping.
bunx wrnexus typecheck .
bunx wrnexus inspect packages .
bunx wrnexus inspect styles .
bunx wrnexus build .Expected result
The commands exit successfully, the build reports the installed UI components and active theme, and the rendered page remains usable before and after hydration.