Document JS monorepo shared-package build dependency pattern in aspireify

[Copilot]

Brownfield JS/TS workspaces often source-link a shared package whose dist/ artifacts must exist before API/web apps start. The existing aspireify guidance did not cover this pattern or the tsc --incremental false-success case where waitForCompletion passes but consumers fail at runtime.

• Added monorepo shared-library guidance (references/javascript-apps.md)

  • New section: Shared library packages in monorepos
  • Documents modeling shared package build as a one-shot resource and gating consumers with .waitForCompletion(shared)
  • Clarifies waitForCompletion vs waitFor semantics for build resources
  • Adds the tsc --incremental emit pitfall and concrete remediations (prebuild cleanup or tsc --build --clean && tsc --build)
  • Includes “When NOT to use this pattern” for registry-published shared packages

• Wired detection/proposal hook in workflow doc (SKILL.md)

  • In 2. Propose, added a pointer to the new section:
    references/javascript-apps.md#shared-library-packages-in-monorepos
  • Added scan heuristic conditions to surface this pattern:
    • root package.json has workspaces
    • workspace package main/exports points at dist/
    • another workspace package depends on it

const shared = builder.addJavaScriptApp("shared-build", "../packages/shared", { runScriptName: "build" });

const api = builder.addJavaScriptApp("api", "../services/api", { runScriptName: "dev" })
    .withHttpEndpoint({ name: "http", env: "PORT" })
    .waitForCompletion(shared);

builder.addViteApp("web", "../apps/web")
    .withReference(api)
    .waitForCompletion(shared)
    .waitFor(api);