Skip to main content

Overview

The Service Orders Management System uses Nuxt 3, which provides flexible build options for different deployment scenarios. You can create either a server-side rendered (SSR) application or a statically generated site.

Build Commands

The application includes several build-related scripts defined in package.json:
npm run build

Available Build Scripts

1

SSR Build (Default)

The build command creates a production-ready SSR application:
package.json
{
  "scripts": {
    "build": "nuxt build"
  }
}
This generates a .output directory containing:
  • Server-side code for handling requests
  • Client-side assets (JavaScript, CSS)
  • Optimized and tree-shaken bundles
2

Static Generation

For static hosting, use the generate command:
package.json
{
  "scripts": {
    "generate": "nuxt generate"
  }
}
npm run generate
This pre-renders all routes and generates a fully static site in the .output/public directory.
3

Preview Production Build

Test your production build locally before deployment:
package.json
{
  "scripts": {
    "preview": "nuxt preview"
  }
}
npm run preview
The preview server runs your built application, simulating a production environment. This is useful for catching issues before deployment.

SSR vs Static Generation

When to Use SSR Build

Choose nuxt build for:
  • Dynamic content that changes frequently
  • User-specific content and authentication
  • Real-time data from APIs
  • Server-side logic and middleware
Deployment targets: Node.js servers, serverless platforms (Vercel, Netlify Functions), Docker containers

When to Use Static Generation

Choose nuxt generate for:
  • Content that doesn’t change often
  • Better performance (no server processing)
  • Lower hosting costs
  • CDN distribution
Deployment targets: Static hosting (Netlify, Vercel, GitHub Pages, AWS S3)
Static generation pre-renders pages at build time. API calls made during generation will use build-time data. Ensure your application can handle this appropriately.

Build Output

After running either build command, you’ll find the output in the .output directory:
.output/
├── public/          # Static assets and pre-rendered pages
├── server/          # Server-side code (SSR builds only)
└── nitro.json       # Build metadata

Optimization Tips

1

Enable Production Mode

Ensure NODE_ENV=production is set during build:
NODE_ENV=production npm run build
This enables:
  • Minification of JavaScript and CSS
  • Tree-shaking to remove unused code
  • Production optimizations in Vue and Nuxt
2

Analyze Bundle Size

Add the --analyze flag to inspect bundle composition:
npm run build -- --analyze
This opens a visual report showing which modules contribute to bundle size.
3

Optimize Images

The application uses @nuxt/image for automatic image optimization. Ensure images are properly configured to leverage:
  • Lazy loading
  • Responsive sizing
  • Modern format conversion (WebP, AVIF)
4

Configure Vite Optimizations

The build uses Vite under the hood. Custom optimizations are defined in nuxt.config.ts:
nuxt.config.ts
vite: {
  define: {
    "process.env.DEBUG": false,
  },
}
This removes debug code from production builds.

Build Process

  1. Preparation: Run nuxt prepare (automatically runs after npm install via postinstall script)
  2. TypeScript Check: Type checking is performed during build
  3. Module Processing: All Nuxt modules are initialized and configured
  4. Vite Build: Client and server code are bundled
  5. Optimization: Code splitting, minification, and tree-shaking
  6. Output Generation: Final artifacts written to .output

Next Steps

Environment Configuration

Configure runtime settings and API endpoints for different environments

Build docs developers (and LLMs) love