…Azure#4968)
Bumps the `core` submodule to latest main, which pulls in tspd's
per-rule reference page generation (microsoft/typespec#11221). Left
as-is, that would orphan Azure's rich hand-written rule pages by
emitting barebones pages at a new location.
Instead, this migrates each rule to the tspd `docs` field and keeps the
generated pages at their existing URLs (net-zero URL change).
## Changes
- **core**: bump submodule to latest main — includes the merged tspd
`--rules-dir` change (microsoft/typespec#11316)
- **86 rules**: add `docs:
fileRef.fromPackageRoot("src/rules/<name>.md")`; rich content now lives
in `packages/*/src/rules/*.md`
- **3 `package.json`** regen-docs scripts: pass `--rules-dir ../rules`
so generated pages stay at `libraries/<lib>/rules/<name>`
- **astro.config**: 5 redirects for rules whose historical slug differs
from the rule name (e.g. `prevent-format` → `no-format`)
- **.gitignore**: ignore the generated `libraries/*/rules/` pages
(regenerated during `build:web`)
- **pnpm-lock**: add `@typespec/events` / `@typespec/sse` workspace
links (new `http-specs` peer deps from the bump)
- **eng/feeds e2e**: adapt `init-templates.e2e.ts` to the compiler's new
`TemplateSource` scaffold API — `ScaffoldingConfig.baseUri` was replaced
by `source?: TemplateSource` (microsoft/typespec#11303). Supersedes
Azure#4965.
- Contributing guide, `create-linter-rule` skill + scaffolder updated to
the `docs`-field workflow
## Validation
- `typespec-azure-core`, `typespec-azure-resource-manager`,
`typespec-client-generator-core` tests pass
- `oxlint` clean
- `pnpm install --frozen-lockfile` passes
- `pnpm regen-docs` clean (no drift)
- init-templates e2e: scaffolding tests pass via the new
`TemplateSource` path (the 2 `validate` tests that `npm install` an
unpublished `@azure-tools/typespec-autorest` version fail only on
registry resolution, unrelated to this change)
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Extracts the self-contained
tsp inittemplate-loading refactor out of #11299 into its own PR.What
Replaces
getExecutionRoot()-based template resolution intsp initwith a first-classTemplateSourceabstraction, with three implementations behind one interface:FileSystemTemplateSource— the default (installed/node) path; readstemplates/from the compiler package root. NogetExecutionRoot()dependency.InMemoryTemplateSource— serves the index and every template file from an in-memory map (used by the standalone single-executable to serve templates offline).RemoteTemplateSource—--templates-url; keeps the untrusted-source confirmation and relative-file resolution.Why
Template loading previously went through the
CompilerHostfilesystem contract anchored atgetExecutionRoot(), which also serves the stdlib. Serving templates from an embedded/offline source required masquerading an in-memory map as a real filesystem and overloadinggetExecutionRoot(). This refactor decouples template resolution from the host FS contract so each context supplies its own source, and leavesgetExecutionRoot()solely for the stdlib.Notes
initdefaults toFileSystemTemplateSource.getTypeSpecCoreTemplates/scaffoldNewProject) and the VS Code extension keep working; the extension threads aTemplateSourcethroughcreate-tsp-project.serverlib.ts/server/types.tsare unchanged.