Expand description
  • Perseus is a blazingly fast frontend web development framework built in Rust with support for major rendering strategies,
  • reactivity without a virtual DOM, and extreme customizability. It wraps the lower-level capabilities ofSycamore
  • and provides a NextJS-like API!
    • ✨ Supports static generation (serving only static resources)
    • ✨ Supports server-side rendering (serving dynamic resources)
    • ✨ Supports revalidation after time and/or with custom logic (updating rendered pages)
    • ✨ Supports incremental regeneration (build on demand)
    • ✨ Open build matrix (use any rendering strategy with anything else, mostly)
    • ✨ CLI harness that lets you build apps with ease and confidence
  • This is the documentation for the Perseus CLI, but there’s also the core package and integrations
  • to make serving apps on other platforms easier!
  • Resources

  • These docs will help you as a reference, but the book should
  • be your first port of call for learning about how to use Perseus and how it works.

Modules

Parsing utilities for arguments.

Constants

The current version of the CLI, extracted from the crate version.

Functions

Builds the subcrates to get a directory that we can serve. Returns an exit code.

Checks if the user has the necessary prerequisites on their system (i.e. cargo and wasm-pack). These can all be checked by just trying to run their binaries and looking for errors. If the user has other paths for these, they can define them under the environment variables PERSEUS_CARGO_PATH and PERSEUS_WASM_PACK_PATH.

Deletes build artifacts in .perseus/dist/static or .perseus/dist/pkg and replaces the directory.

Deletes a corrupted ‘.perseus/’ directory. This will be called on certain error types that would leave the user with a half-finished product, which is better to delete for safety and sanity.

Deploys the user’s app to the pkg/ directory (can be changed with -o/--output). This will build everything for release and then put it all together in one folder that can be conveniently uploaded to a server, file host, etc. This can return any kind of error because deploying involves working with other subcommands.

Ejects the user from the Perseus CLi harness by exposing the internal subcrates to them. All this does is remove .perseus/ from the user’s .gitignore and add a file .ejected to .perseus/.

Builds the subcrates to get a directory that we can serve. Returns an exit code.

Exports a single error page for the given HTTP status code to the given location.

Checks if the user has ejected or not. If they have, commands like clean should fail unless --force is provided.

Prepares the user’s project by copying in the .perseus/ subcrates. We use these subcrates to do all the building/serving, we just have to execute the right commands in the CLI. We can essentially treat the subcrates themselves as a blackbox of just a folder.

Builds the subcrates to get a directory that we can serve and then serves it. If possible, this will return the path to the server executable so that it can be used in deployment.

Serves an exported app, assuming it’s already been exported.

Runs static generation processes directly so the user can see detailed logs. This is commonly used for allowing users to see dbg! and the like in their builder functions.

Runs the commands to run the server directly so the user can see detailed logs.

Runs the commands to build the user’s app to Wasm directly so they can see detailed logs.

Runs plugin tinkers on the engine and returns an exit code. This doesn’t have a release mode because tinkers should be applied in development to work in both development and production.