Shared Libraries Study Portal

Key takeaways

two call sites are a library. Extracting earlier produces premature abstractions shaped by a single caller. If a planned package turns out to have only one real consumer, defer it.

@dloizides/*) solves exactly one cross-cutting problem, so services and apps pull in only what they need.

a private committed local-packages feed (package source mapping + Dockerfile COPY), not nuget.org. The @dloizides/* NPM packages go to npm and a private GitHub registry.

existing imports don't churn; migrate gradually; delete dead local files afterward.

manage.sh create-app composes four generators into one runnable product wired onto the shared stack, auto-injects compiling skeletons for optional toggles (billing / storage / custom-domains / email / GDPR), and emits a REGISTRATION.md (snippets to register the service) plus a per-product RUNBOOK.md (owner-gated DNS / Keycloak realm / Stripe / S3 / email / analytics steps).

and reaches login → dashboard before any product features exist — proof the shared bricks are solid and composable.

• *Extract on the second use, not the first.* One call site is a feature;
• One package, one concern. Each shared library (backend NuGet or frontend
• Two ecosystems, two distribution channels. In-house .NET packages ship via
• Adopt via shims. Re-export a shared package through a thin local module so
• The scaffolder is the capstone, and it's synthesis — not extraction.
• "It already runs" is the acceptance test. A freshly scaffolded app builds