@voltro/cli 0.52.0 → 0.53.0

package/dist/updateCommand-5gFVfK5q.js

@@ -1,2 +0,0 @@
-import { f as e, p as t } from "./updateCommand-BMk2e4ky.js";
-export { e as runApplyCodemods, t as runUpdateCommand };

package/dist/webDev-CZbTsDcH.js

@@ -1,2 +0,0 @@
-import { b as e, v as t } from "./webDev-BgWL9gKV.js";
-export { t as tryRunWebServe, e as walkPagesTree };

package/templates/apps/changelog/scripts/generate-rss.mjs

@@ -1,38 +0,0 @@
-// Generate public/rss.xml from content/releases/*.mdx using the SAME
-// @voltro/changelog primitives the pages use (`loadReleases` +
-// `renderReleaseRss`). Runs BEFORE `voltro build` so Vite copies the file
-// into the build output (publicDir = <app>/public) and `voltro start`
-// serves it as application/xml.
-//
-// Why a separate Node script and not a page route: the web SSG renders
-// HTML pages only — a feed is a non-HTML artifact, so it's emitted as a
-// static file rather than an `rss.xml.tsx` route. Run via `tsx` so the
-// import resolves whether @voltro/changelog points at its TS source
-// (in-workspace dev) or its built dist (a normal install).
-import { readdirSync, readFileSync, writeFileSync, mkdirSync } from 'node:fs'
-import { dirname, join } from 'node:path'
-import { fileURLToPath } from 'node:url'
-import { loadReleases, renderReleaseRss } from '@voltro/changelog'
-
-const appRoot = join(dirname(fileURLToPath(import.meta.url)), '..')
-const releasesDir = join(appRoot, 'content', 'releases')
-
-// Read each .mdx file into the { path: contents } map loadReleases expects.
-const sources = {}
-for (const file of readdirSync(releasesDir)) {
-  if (file.endsWith('.mdx')) sources[file] = readFileSync(join(releasesDir, file), 'utf8')
-}
-
-const releases = loadReleases(sources)
-// The base URL each release links under (<siteUrl>/<slug>). Set SITE_URL in
-// your deploy env; localhost is the dev default.
-const siteUrl = process.env.SITE_URL ?? 'http://localhost:{{port}}'
-const xml = renderReleaseRss(releases, siteUrl, {
-  title: '{{capProjectName}} Changelog',
-  description: 'Product updates and release notes.',
-})
-
-const publicDir = join(appRoot, 'public')
-mkdirSync(publicDir, { recursive: true })
-writeFileSync(join(publicDir, 'rss.xml'), xml)
-console.log(`rss.xml — ${releases.length} release(s) → public/rss.xml`)

package/templates/apps/changelog/src/lib/releases.ts

@@ -1,21 +0,0 @@
-// The single source of releases for every page. The MDX files under
-// content/releases/ are read at build time via Vite's raw glob (works in
-// dev, SSR, and the static build). `import: 'default'` yields each file's
-// contents as a string — exactly the shape `loadReleases()` expects. The
-// loader parses the frontmatter, renders the markdown body, sorts newest-
-// first, and skips any file missing `version` / `releasedAt`.
-import { loadReleases, type Release } from '@voltro/changelog'
-
-const sources = import.meta.glob('../../content/releases/*.mdx', {
-  query: '?raw',
-  import: 'default',
-  eager: true,
-}) as Record<string, string>
-
-/** All releases, newest first. */
-export const releases: ReadonlyArray<Release> = loadReleases(sources)
-
-export const releaseBySlug = (slug: string): Release | undefined =>
-  releases.find((r) => r.slug === slug)
-
-export type { Release }

package/templates/apps/frontend-static-blog/src/content/posts.ts

@@ -1,64 +0,0 @@
-// The content source for the blog.
-//
-// This is a plain in-repo array — the simplest stand-in for a CMS. In a
-// real app, swap the body of `getStaticPaths` + the page loader to read
-// from your CMS / database / filesystem instead. NOTHING else changes:
-// the build still pre-renders one HTML file per entry.
-//
-// Because this module is imported by both the index page (the list) and
-// the [slug] page (the detail) AND by `getStaticPaths`, it is the single
-// source of truth for "which posts exist".
-
-export interface Post {
-  /** URL segment — `/blog/<slug>`. Must be unique + DNS-safe. */
-  readonly slug: string
-  readonly title: string
-  /** ISO date, shown + used for ordering. */
-  readonly date: string
-  /** One-line summary — feeds the list + the `<meta name="description">`. */
-  readonly excerpt: string
-  readonly readingMinutes: number
-  /** Body paragraphs, separated by a blank line. */
-  readonly body: string
-}
-
-export const posts: ReadonlyArray<Post> = [
-  {
-    slug: 'hello-static',
-    title: 'Why this blog ships zero JavaScript',
-    date: '2025-01-15',
-    excerpt: 'Every page is pre-rendered at build time, so the browser downloads HTML and nothing else.',
-    readingMinutes: 3,
-    body: `This page was rendered ONCE, when you ran \`voltro build\`. The result is a flat \`dist/blog/hello-static/index.html\` that any CDN can serve in single-digit milliseconds.
-
-There is no server rendering per request, no React hydration on the list page, no rpc client on the wire. The list page even declares \`interactive = 'none'\`, which strips every \`<script>\` the framework would otherwise emit.
-
-When you DO need a sprinkle of interactivity — a reading-progress bar, a copy button, a comment box — you reach for an island instead of hydrating the whole tree. Read the next post for how that works.`,
-  },
-  {
-    slug: 'islands-not-hydration',
-    title: 'Islands: hydrate the 5% that moves',
-    date: '2025-01-22',
-    excerpt: 'A static page with one interactive widget should ship one widget of JavaScript — not the whole page.',
-    readingMinutes: 4,
-    body: `Look at the top of this page: a thin progress bar tracks how far you have scrolled. That bar is an ISLAND — a single component the framework hydrates inside otherwise-static HTML.
-
-This page declares \`interactive = 'islands'\`, so the framework renders the article once and only attaches React to the \`island()\`-wrapped component. The surrounding HTML has zero React lifecycle running.
-
-Each island picks WHEN it wakes up via a hydrate strategy: \`load\` (immediately), \`idle\`, \`visible\` (on scroll-into-view), or \`interaction\` (on first click). The progress bar uses \`load\` because it must track scrolling from the very first frame.
-
-The lesson: don't default to \`islands\` because it sounds fast. Use it when most of the page is static and only a few widgets move. A dashboard where everything is interactive wants \`full\` hydration instead.`,
-  },
-  {
-    slug: 'cms-to-ssg',
-    title: 'From CMS to static pages with getStaticPaths',
-    date: '2025-02-03',
-    excerpt: 'Enumerate your content once; the build emits one pre-rendered page per entry.',
-    readingMinutes: 3,
-    body: `A dynamic route like \`src/pages/blog/[slug].tsx\` matches infinitely many URLs. To pre-render it statically, the build needs to know WHICH slugs exist — that is what \`getStaticPaths\` answers.
-
-In this template, \`getStaticPaths\` maps over the \`posts\` array in \`src/content/posts.ts\`. Point it at a CMS API, a database query, or a folder of markdown files instead, and the build will pre-render exactly those pages — the Next.js "static generation from a content source" pattern, with no extra config.
-
-URLs you do not enumerate simply are not built. If a page ALSO sets \`renderMode = 'ssr' | 'isr'\`, \`voltro start\` renders the un-enumerated ones on demand; a pure \`'static'\` page 404s for unknown slugs, which is exactly what you want for a fixed content set.`,
-  },
-]