Engineering note
Nuxt Layers and shared packages: choosing what belongs where
At X Enterprises, my work includes Nuxt Layers and internal npm packages to share logic and components across websites. These tools solve related problems, but the boundary between them deserves an explicit decision.
By Walelgn Dagne · Nuxt & Vue.js developer
Start with what the sites actually share
Before extracting a shared foundation, list what repeats: application configuration, layout, components, styling, or business logic. Similar-looking pages do not always have the same requirements. A shared implementation is useful when its consumers should evolve together.
For example, a common navigation layout across a family of sites is a different kind of reuse from a date-formatting utility. The layout depends on the application’s conventions; the utility may be useful anywhere.
Use a layer for a shared Nuxt foundation
Nuxt Layers let an application extend another Nuxt project. That makes a layer a useful home for shared application configuration and UI conventions. A consuming application can build on that foundation while providing its own content and site-specific behavior.
Keep the layer’s responsibility easy to explain. A layer that contains every exception from every site becomes difficult to change. When two sites need substantially different behavior, consider whether that behavior belongs in each application instead.
Use a package for a defined reusable interface
An internal npm package can expose a focused set of utilities, types, or components. The important part is a clear public interface: consumers should know what they can import and which assumptions they must satisfy.
Layers can also be distributed as packages, so this is not a choice between mutually exclusive delivery methods. The design question is whether the shared code is an application foundation or a focused dependency.
Make changes with the consumers in view
For a shared change, identify the sites that consume it and the behavior they depend on. Check representative pages, configuration overrides, and any affected integrations. A build passing in the shared project alone does not establish that every consumer still behaves correctly.
Write down the reason for the shared boundary. That short explanation is useful when the next feature request arrives: it gives the team a way to decide whether to extend the common code or keep a change local.