Valaxy 1.0 is here. You can still start with a Markdown post, add a Vue component when you need interaction, and publish the site as static files. This release connects writing, management, rendering, and extensions more closely: everyday maintenance has more complete tools, builds follow one rendering path, and features such as diagrams and music are installed as needed.

This article explains what those changes mean for blog authors, theme developers, and addon authors.

Start with a post ​

Valaxy keeps content in project files. A post can use Markdown for text, images, and code, and reference Vue components directly. When an article needs an interactive example, calculator, or custom card, you can maintain the component alongside the post and preview both in the development server.

Content and presentation have their own configuration. site.config.ts describes the site, while valaxy.config.ts configures the theme, addons, and framework behavior. Themes handle layout and appearance. Yun focuses on personal blogs; Press provides documentation navigation, sidebars, and content organization. This website’s documentation and blog share one Press site.

The workflow can grow with your content: finish a post, then add components, choose a theme, or enable an addon as needed. Markdown, images, and Git history remain part of the project. See Posts and Vue in Markdown.

Visual tools for everyday maintenance ​

During development, Valaxy DevTools brings post, configuration, and addon management into Vite DevTools. You can browse articles, edit metadata, organize categories and tags, and save changes back to project files. Page debugging exposes the current route and frontmatter, helping answer questions such as why a page uses a particular layout.

Addon management distinguishes browsing, installing a dependency, and enabling it in configuration. After installation, follow the addon’s setup instructions. Review the preview before package or configuration changes so you can see which files an action affects.

DevTools runs with the development server and is excluded from production builds. Authors who prefer their editor can use the VS Code extension; desktop authors can explore the Yunzhan public preview. These tools work with project content. Their individual documentation describes supported workflows.

One build and rendering implementation ​

The build foundation in 1.0 is Vite 8 and Rolldown. Hot updates still let you preview changes to posts, components, and configuration. For publication, the build produces browser assets and uses Vue SSR to generate static pages.

The legacy JSDOM-based vite-ssg engine has been removed. Valaxy now uses its built-in SSG engine, combining Vue SSR with string processing. Builds no longer provide window, document, or navigator through a simulated DOM. Themes and addons must run browser-dependent operations on the client; a successful development preview alone does not establish static-build compatibility.

Initial styling has changed too. Critical CSS inlining has been removed, and a FOUC guard coordinates initial visibility with stylesheet readiness. SSG produces HTML while CSS loads from build assets. Using SSG does not imply that every style is inlined or that CSS makes no additional requests. See SSR compatibility for browser-only components and hydration.

Custom build configuration also needs attention. Historical Rollup manualChunks examples do not describe the current framework implementation: Valaxy uses Rolldown’s codeSplitting configuration. Build duration and output size depend on content, themes, addons, hardware, and cache state. Measure them on your own site.

Async rendering across content outputs ​

A post appears in several places. Its page displays the body, a list shows an excerpt, search extracts searchable text, and RSS distributes content to subscribers. Each path processes Markdown and must correctly await asynchronous steps such as code highlighting.

Valaxy 1.0 gives these paths shared async rendering semantics. Shiki loads languages asynchronously when needed, and callers with the same configuration can reuse a highlighter. Addon authors can work with one rendering contract, reducing the risk that an output path still assumes synchronous rendering.

Shared semantics do not make every output identical. Excerpts select content, search extracts text, and feeds handle links. Browser interactions cannot simply become interactive RSS content. When extending Markdown, check the page, excerpt, and other outputs your site uses. See the Markdown guide for supported syntax.

Responsibilities across core, themes, and addons ​

In 1.0, Mermaid diagrams and the Meting music player are provided by dedicated addons. Sites that need them install and enable the corresponding addon, then migrate existing configuration as documented. Mermaid Markdown fences remain usable; the legacy music-player switch needs migration.

For authors, enabling a feature now includes its addon installation and configuration. For maintainers, diagrams and music integrations have their own dependencies and release locations, with a defined feature scope. Bundle impact, third-party scripts, and service requirements still depend on the individual addon.

Other extensions include comments, search, galleries, and the Moments timeline for short posts. Browse official addons for setup instructions.

AI tools can inspect the framework’s view of a post ​

An AI coding assistant can already edit Markdown files. Valaxy adds access to the framework’s resolved view: the final route, selected layout, draft status, and potential local-link problems. Configuration and hooks can affect those values, so reading a source file alone may not answer these questions.

The local MCP service is disabled by default. When enabled, it exposes read-only tools for querying, reading, and checking content. It does not create or edit posts through MCP or expose management operations. DevTools editing and MCP are configured independently; the production site includes no local MCP service.

You can also inspect a post without connecting MCP. From the blog directory, run:

pnpm exec valaxy inspect --file pages/posts/hello.md --json
pnpm exec valaxy check --file pages/posts/hello.md --json

Replace the path with your own post. These commands help authors and coding assistants verify resolved content after an edit. A full build still validates the publishing pipeline. See Work with AI for connection details and content visibility.

Upgrade according to the features you use ​

Before upgrading, save your project and lockfile, and ensure that local and deployment environments use Node.js 22.12.0 or later. Then review the parts that apply to your site:

Theme developers should check a production build, including direct route access, mobile layouts, overlays, and interactive components. Configuration alone cannot establish their runtime behavior.

Use the complete migration guide for individual steps. If you are new to Valaxy, follow Getting Started, or explore the 1.0 release showcase to see how Markdown, themes, and DevTools work together.