v1.11.1

Patch Changes

• #68 441372f Thanks @flyon! - linked create-app now stamps the chosen app identity into the scaffolded app. The app template ships without ${var} scaffold placeholders (so a raw clone boots on defaults), so create-app writes the real per-app values after cloning: .env/.env.example (APP_NAME, APP_PREFIX), package.json name/displayName, the runtime linkedPackage(...) id in src/package.ts, and the pm2 / VS Code launch names. Both the --app-name flag and the interactive prompt now produce an app that carries the chosen name (previously every scaffolded app inherited the template defaults).

v1.11.0

Minor Changes

• #66 e11d012 Thanks @flyon! - Native .env support, app-name for the client bundle, and standalone SSR single-instance fixes.

  • .env loading — ensureEnvironmentLoaded now loads the app environment from a flat .env via Node's native process.loadEnvFile (no env-cmd dependency) when no .env-cmdrc.json is present. .env-cmdrc.json still takes priority when it exists (profile-based, honours --env a,b), so existing apps are unaffected. When neither file exists the cli no longer hard-exits — it relies on the ambient environment (e.g. env injected by a host at spawn time). The original shell environment is still re-applied last, so it wins over file values.
  • process.env.APP_NAME is now inlined into the client bundle (like SITE_ROOT/NODE_ENV), so components can render the app display name; defaults to 'Linked App' when unset.
  • Standalone SSR now dedupes and bundles the React-context holders (@_linked/server-utils, @_linked/react) into a single instance, fixing a null AppContext during SSR in ejected/standalone apps.

v1.10.0

Minor Changes

• #64 b16a090 Thanks @flyon! - - Standalone apps: framework packages (@_linked/* / lincd-*) are excluded from Vite's dep-optimizer so the browser loads one copy of each — fixes class-name duplication (Person→Person2) that broke cross-runtime shape lookup and the app's write path.
  • The client build now defines process.env.SITE_ROOT / NODE_ENV (webpack EnvironmentPlugin parity); apps add their own public env vars via define in their vite.config.ts.
  • A single FRAMEWORK_PKG_PATTERNS constant now drives every single-instance lever (optimizeDeps.exclude, ssr.noExternal).

v1.9.1

Patch Changes

• #62 61be66a Thanks @flyon! - Workspace-member clones (e.g. per-branch apps/<app>/<branch> checkouts with symlinked @_linked/* sources) now boot under linked start: their linked deps are excluded from Vite's dep optimizer so the workspace source resolver handles them, instead of esbuild failing to pre-bundle symlinked package subpaths (No known conditions for ./shapes/SHACL).

v1.9.0

Minor Changes

• #59 98dbb5a Thanks @flyon! - ESM-only. Dropped the CommonJS build; ships ES modules only (type: module, no require export condition, no lib/cjs). Fixed the root types field. CJS consumers on Node 22+ can require() it (sync ESM) or use dynamic import().

• #59 647417b Thanks @flyon! - Standalone dev + template git-clone scaffolding:

  • Standalone dev resolution — createViteConfig now detects when an app is NOT inside a workspace (lib-only npm install of @_linked/*) and resolves those deps via import → lib/esm (conditions ['module','node']) instead of the development → src export they don't ship. Fixes "Failed to load @_linked/server/shapes/LinkedServer" on a clean install. Monorepo/workspace dev is unchanged.
  • create-app clones the template repo — new apps are scaffolded by git clone-ing linked-cm/app-template (single source of truth, same repo CN's server-side project creation uses) instead of copying a bundled defaults tree. The bundled defaults/app-with-backend is removed.
  • Removed the orphaned tsx register/register-css-only loaders (+ tsx dep); apps run plain linked start (Vite handles TS transform).

v1.8.2

Patch Changes

• #57 e8385bd Thanks @flyon! - CLI sub-template imports updated to use @_linked/core instead of legacy
  lincd/...:

  • defaults/shape.ts — Shape + NamedNode from @_linked/core
  • defaults/package/src/package.ts — linkedPackage from @_linked/core/utils/Package (clean 1:1 swap; @_linked/core exports it identically)
  • defaults/package/src/ontologies/example-ontology.ts — NamedNode + createNameSpace from @_linked/core (unused lincd-jsonld import dropped)

  Important caveat — TODO comments inline in the template files explain:
  the package.ts template is a clean working swap. The shape.ts and
  ontologies/example-ontology.ts templates' generated output will fail
  to compile because @_linked/core doesn't export NamedNode or
  Literal as runtime classes — the new framework architecture moved past
  direct node construction. Templates need a rewrite to emit the modern
  getter-only @_linked/* shape pattern (see @_linked/schema/shapes/Person.ts).
  The import-path change is a deliberate signal-of-intent that lands
  incomplete; the actual template rewrite is tracked as downstream
  Shape-Builder / Ontology-Manager review work.

  Users of linked create shape Foo and linked create package Bar: if you
  hit "Cannot find name NamedNode" or "Cannot find name Literal" errors
  in scaffolded files, you've hit the documented gap. The fix path is the
  template rewrite, not reverting to legacy lincd.

  Context: see create-now plan-011 report (docs/reports/009-legacy-lincd-eradication.md).

v1.8.1

Patch Changes

• #54 5d475c7 Thanks @flyon! - setup-publish now generates publish workflows that author the changesets "Version Packages"
  PR (and, for dual-branch, the post-release sync) via an org GitHub App token
  (actions/create-github-app-token, org secrets RELEASE_APP_ID / RELEASE_APP_PRIVATE_KEY)
  instead of the default GITHUB_TOKEN — so those PRs' checks run without a manual "Approve and
  run" gate. The dual-branch template's version-only sync-version-to-dev job is replaced by a full
  back-merge main -> dev (carrying the version bump, CHANGELOG, and changeset deletions, so dev
  never re-releases consumed changesets). --configure-github also enables "Allow auto-merge" so the
  back-merge PR self-merges once checks pass.

v1.8.0

Minor Changes

• #52 3b5d645 Thanks @flyon! - Four scaffolding/runtime fixes from first external-user feedback:
  • Template src/package.ts now imports from @_linked/react/package instead of @_linked/core/utils/Package. Core's LinkedPackageObject doesn't expose linkedComponent / linkedSetComponent (they're React-only) — the old import caused tsc to error on a fresh scaffold the moment a user added their first shape. Requires @_linked/react@>=1.3.1 (which fixed the recursion in linkedPackage).
  • linked CLI swapped tsx for a custom esbuild-based ESM loader for TS/TSX user code. tsx hardcodes esbuild's default decorator emit (TC39 standard) and ignores experimentalDecorators in the user's tsconfig — silently breaking @literalProperty / @objectProperty / @linkedShape everywhere, since @_linked/core ships legacy-signature (target, propertyKey, descriptor) decorators. The new loader at lib/esm/loaders/ts-loader.mjs reads the user's tsconfig.json, force-enables experimentalDecorators: true in the esbuild tsconfigRaw, preserves import-attribute (with { type: 'json' }) syntax, and backfills extension-less relative imports. Net effect: legacy decorator emit just works, no esbuild-bundle workaround needed for scripts.
  • create-app now writes an empty yarn.lock in the new app. Without it, Yarn climbs ancestor dirs looking for a project root and may decide an ancestor's stray yarn.lock is "the project" — aborting install with "the nearest package directory doesn't seem to be part of the project declared in ".
  • Template linked.backend.storage.ts and src/linked.frontend.storage.ts use with { type: 'json' } for the JSON dataset config imports, replacing the deprecated assert { type: 'json' } syntax (which Node 22+ rejects).

v1.7.0

Minor Changes

• #50 182b907 Thanks @flyon! - create-app now picks between npm and yarn deliberately instead of silently preferring yarn:

  • If only one of npm / yarn is on PATH, that one is used.
  • If both are installed AND the user is running interactively, create-app asks Package manager [npm/yarn] (default: yarn):. Empty answer keeps the old default (yarn). Typing npm or yarn overrides.
  • If both are installed but flags (--app-name / --app-prefix / --app-domain) were passed, no prompt — yarn wins, matching the previous non-interactive default.
  • The chosen package manager flows through the install step AND the final "next command" hint, so the copy-paste line at the end is always cd my-app && npm start or cd my-app && yarn start matching what was actually installed (instead of always showing npm start with a yarn comment).

  Why this matters: scaffolding with yarn but then running npm start (without re-running npm install) used to leave critical packages unresolved at webpack-compile time. Picking one PM and reusing it removes that footgun.

v1.6.4

Patch Changes

• #48 dce9cb5 Thanks @flyon! - Template tsconfig.json switched from moduleResolution: "node" to moduleResolution: "bundler". The classic Node resolver doesn't honor the exports field in package.json, and @_linked/react (and friends) declare types only inside exports[".".types], not as a top-level types field. The result was a fresh scaffold compiling cleanly with yarn install but exploding under webpack/ts-loader:

  TS2307: Cannot find module '@_linked/react' or its corresponding type declarations.
    There are types at '.../node_modules/@_linked/react/lib/esm/index.d.ts', but
    this result could not be resolved under your current 'moduleResolution' setting.
    Consider updating to 'node16', 'nodenext', or 'bundler'.
  

  bundler is the right choice for a webpack-bundled app — it honors exports, doesn't require .js extensions on relative imports, and doesn't enforce full ESM strictness.