Lifecycle

One of the core design philosophies of OpenPress is to align the lifecycle of a document with the lifecycle of modern software development. This means that the writing, previewing, validation, and deployment of a document follow the same rhythm as general front-end frameworks (like Vite or Astro).

Why do we need lifecycle commands?

In traditional document editors, the state of a document is usually only “editing” or “exported.” However, in OpenPress, a document is treated as code (Docs as Code). This brings several important conceptual shifts:

1. Separation of Development and Preview: When writing content, we need an environment that provides instant feedback (hot module replacement), displays comments, and allows Agent intervention. This is the meaning of the dev phase.
2. Build and Validation: Before publication, a document must undergo strict validation. We must ensure that all components render correctly, all links are valid, and there are no TypeScript type errors. This is the role of build and typecheck.
3. Static Distribution: The final output document should not depend on any specific server environment. They are compiled into pure static files that can be deployed to any static site hosting service.

Core Loop Concept

Through five standard commands, OpenPress defines a clear loop:

• Start (Create): Create a new workspace. This phase isn’t just about creating folders; it establishes the type of document (like a presentation or report) and sets up all the infrastructure needed for subsequent phases.
• Iteration (Dev): This is the phase where authors and Agents stay the longest. During this phase, the system focuses on developer experience: providing a dev server, supporting instant style and content updates, and opening various interfaces to assist with debugging.
• Validation (Typecheck): For advanced authors using TypeScript, this phase ensures the type safety of custom components or advanced configurations, preventing runtime errors.
• Packaging (Build): Converts the dynamic development environment into static production artifacts. This phase removes all development-only tools (like the workbench interface) and optimizes the output.
• Confirmation (Preview): Before final deployment, provides a local preview that accurately simulates the production environment, allowing the author to confirm the exact appearance readers will ultimately see.

This lifecycle, consistent with front-end development, not only lowers the learning barrier for developers but more importantly, it establishes a predictable, automatable, and highly stable production process for documents.