Ctrl + K

Project Structure

Standard structure of a Pulsar project

Project Structure

Pulsar encourages a clear separation between application logic and web-facing assets.

The framework does not enforce a rigid folder layout, but it strongly promotes architectural clarity over convenience.

Core Separation

There is one structural rule in Pulsar that is non-negotiable: application code and web assets must live in separate directories.

lib/
web/

The lib/ directory contains your Dart application logic. The web/ directory contains everything that is exposed to the browser.

Mixing components inside web/ or placing web assets inside lib/ is intentionally discouraged. This separation prevents fragile imports and keeps UI logic independent from deployment concerns.

Within those boundaries, Pulsar suggests — but does not require — a simple, domain-oriented structure.

lib/
├── app.dart
├── components/
├── pages/
├── layouts/
├── routing/
├── styling/
web/
├── index.html
├── main.dart
├── styles.css
├── styles/

The lib/ directory

This is where your application lives. Components, pages, layouts and routing logic belong here.

  • components/ — reusable UI building blocks
  • pages/ — route-level components
  • layouts/ — long-lived structural components
  • routing/ — router configuration and composition
  • styling/ — domain styling classes (ButtonStyles, CardStyles, etc.)

Folder names are conventions, not requirements. What matters is that architectural roles remain clear.

The web/ directory

The web/ directory contains static assets and the application entry point.

  • index.html — HTML entry point
  • main.dart — application bootstrap
  • styles.css — global styles, loaded by convention
  • styles/ — component-level or feature-specific styles

By convention, global styles live in web/styles.css. This file defines the visual baseline of the application.

Pulsar values clarity over enforcement. Structures are recommendations meant to scale with the application, not rules imposed by the framework.