Vue.js 77 🟢 Nuxt Modules, Server Engine Rules, and Auto-Imports System - KandZ

⏱️ Estimated read: 17 min | |

Nuxt’s power comes not just from routing and data fetching, but from three interlocking systems that make the framework extensible, deployable, and ergonomic. Modules let you package and share framework modifications. The Nitro server engine compiles your server code into a standalone output that runs anywhere. Auto-imports eliminate the boilerplate of explicit imports while preserving type safety. Each system solves a distinct problem, and together they explain why Nuxt applications feel cohesive rather than assembled.

This chapter examines these three systems in depth. It covers how local and distributed modules extend Nuxt’s core, how Nitro’s rules govern server middleware and plugin execution, and how auto-imports work under the hood without sacrificing production tree-shaking.

Key point: Nuxt’s module system, Nitro engine, and auto-import mechanism are not independent features—they share the same directory conventions and execution context, which is why understanding one reinforces the others.

Why these systems exist

The extension problem. A framework cannot anticipate every project’s needs. Hardcoding every integration—authentication, CMS connectors, image optimization, analytics—would make Nuxt bloated and unmaintainable. Modules exist because they allow the community to extend the core without touching it . A module is an async function that runs at build time, with access to Nuxt’s internals through hooks. It can register components, add server handlers, modify build configuration, and inject plugins. This separation means the core stays lean while the ecosystem provides depth.

The deployment fragmentation problem. A Node.js server, a serverless function, and a static site have incompatible execution models. Without abstraction, deploying the same Nuxt application to different targets would require rewriting server code for each. Nitro solves this by compiling the server/ directory into a standalone output independent of node_modules . The same handler that runs as Express-style middleware on a Node server becomes a serverless function on Vercel or Netlify. This portability is not automatic in most frameworks; it is Nitro’s central design goal.

The import verbosity problem. Vue’s Composition API requires importing ref, computed, onMounted, and every other function explicitly. Nuxt applications additionally use composables like useFetch, useRoute, and useState. Writing import statements for each of these in every file is tedious and adds visual noise. Auto-imports eliminate this boilerplate while preserving tree-shaking: Nuxt analyzes what you actually use and includes only those imports in production . The trade-off is that auto-imports rely on context—calling useRuntimeConfig() outside a proper Nuxt context throws an error—but the ergonomic gain justifies the constraint.

a. Nuxt Modules

A Nuxt module is a function that runs during the build process and can modify nearly every aspect of the framework. Local modules live in the modules/ directory at the project root, and Nuxt registers them automatically without requiring changes to nuxt.config.ts . The convention is straightforward: a file at modules/hello.ts or modules/hello/index.ts becomes a module named hello.

The basic structure of a local module uses defineNuxtModule from nuxt/kit, a helper subpath that avoids adding @nuxt/kit as a direct dependency.

// modules/analytics/index.ts — a local module that adds an API route and a component
import { addComponentsDir, addServerHandler, createResolver, defineNuxtModule } from 'nuxt/kit'

export default defineNuxtModule({
  // meta.name identifies the module in logs and debugging
  meta: { name: 'analytics' },

  // setup runs once during Nuxt initialization
  setup() {
    // createResolver resolves paths relative to this module file
    const resolver = createResolver(import.meta.url)

    // Register a server handler at /api/analytics/collect
    addServerHandler({
      route: '/api/analytics/collect',
      handler: resolver.resolve('./runtime/collect.post')
    })

    // Register a components directory with a path prefix to avoid name collisions
    addComponentsDir({
      path: resolver.resolve('./runtime/components'),
      pathPrefix: true
    })
  }
})

The module’s runtime files must live in a runtime/ subdirectory with an app/ structure mirroring the main application. A component intended for the client goes in modules/analytics/runtime/app/components/, while a server handler goes in modules/analytics/runtime/collect.post.ts . This separation exists because modules are compiled in a different context than application code, and placing runtime files in the wrong location breaks type checking.

Modules execute in a defined order. Modules listed in nuxt.config.ts run first, followed by local modules from the modules/ directory in alphabetical order . To control ordering, prefix directory names with numbers: 1.auth/ runs before 2.analytics.ts. This ordering matters when one module depends on another’s configuration or injected utilities.

Distributed modules from npm follow the same pattern but are registered explicitly in nuxt.config.ts.

// nuxt.config.ts — registering a published module with inline options
export default defineNuxtConfig({
  modules: [
    // Package name resolved from node_modules
    '@nuxtjs/tailwindcss',
    // Array form passes options to the module
    ['@nuxtjs/google-fonts', { families: { Inter: true } }]
  ]
})

A module can be disabled without uninstalling by setting its config key to false in nuxt.config.ts . This is useful when a module is inherited from a layer but not needed in the current project.

b. Nitro Server Engine Rules

Nitro is Nuxt’s server engine, built on the h3 HTTP framework . It handles API routes, server middleware, and the production build output. Understanding Nitro’s execution rules is essential because the server directory operates under different constraints than the app/ directory.

Server middleware versus route middleware. These are distinct systems with different execution contexts. Server middleware in server/middleware/ runs on every incoming HTTP request before any route handler executes. It can modify requests, log activity, or terminate requests early by returning a response . Route middleware in app/middleware/ runs during Vue navigation, either on the server during SSR or on the client during client-side routing. Confusing the two is a common source of bugs.

// server/middleware/logger.ts — runs on EVERY server request
export default defineEventHandler((event) => {
  // event.method is "GET", "POST", etc.
  // event.path is the full request path
  console.log(`[${event.method}] ${event.path}`)
  // No return value: request continues to the next handler
})

// app/middleware/auth.ts — runs during ROUTE navigation, not every HTTP request
export default defineNuxtRouteMiddleware((to) => {
  // This executes before rendering a protected page
  // It does NOT run for API requests or static assets
  if (!isAuthenticated()) {
    return navigateTo('/login')
  }
})

Nitro plugins versus app plugins. Nitro plugins in server/plugins/ execute once when the server starts, not per-request. In serverless environments, the server boots on each cold start, so plugins run then, but they are not awaited . App plugins in app/plugins/ execute during Vue application initialization, once per server render or client hydration. Nitro plugins are appropriate for database connections, error handlers, and shutdown hooks. App plugins are for Vue-specific initialization like providing global utilities.

The $fetch direct-call rule. When $fetch is called on the server, Nitro intercepts it and directly invokes the corresponding handler function without an HTTP round trip . This is a server-only optimization. On the client, the same $fetch call makes a real network request. The rule matters because it means internal API calls during SSR have no network overhead—but it also means you cannot rely on HTTP-level middleware (like external proxies) intercepting those calls.

Typed API routes. Nitro generates TypeScript types for API routes automatically when handlers return values instead of using res.end() . This means $fetch('/api/users') is fully typed: the return type of the handler becomes the return type of the fetch call. Using res.end() breaks this type generation, which is why returning objects is the recommended pattern.

c. Auto-Imports System

Nuxt auto-imports Vue APIs, its own composables, and files from designated directories. The system is powered by unimport, which scans code for identifiers and injects imports only for what is actually used . This is not a global namespace pollution; it is selective inclusion at build time.

Directory-based auto-imports. Three directories in the app/ folder are scanned automatically: components/, composables/, and utils/ . A file at app/composables/useCounter.ts exporting a function called useCounter becomes available everywhere without import.

// app/composables/useCounter.ts — auto-imported as useCounter()
export const useCounter = () => {
  // useState is a Nuxt composable, also auto-imported
  return useState('count', () => 0)
}

<!-- app/pages/index.vue — no imports needed -->
<script setup lang="ts">
// useCounter is auto-imported from app/composables/useCounter.ts
// ref is auto-imported from Vue
const count = useCounter()
const doubled = computed(() => count.value * 2)
</script>

The scanning boundary. Nuxt only scans the top level of app/composables/. A file at app/composables/nested/utils.ts is not auto-imported . To include nested files, either re-export them from an index file or configure imports.dirs in nuxt.config.ts. This boundary prevents accidental exposure of internal helpers and keeps the auto-import surface predictable.

Server-side auto-imports. In the server/ directory, Nuxt auto-imports exported functions and variables from server/utils/ . A utility file at server/utils/db.ts exporting a query function makes query available in any server handler without import.

// server/utils/db.ts — auto-imported in all server handlers
export const query = async (sql: string) => {
  // Placeholder for actual database query
  return []
}

// server/api/users.get.ts — query is auto-imported
export default defineEventHandler(async () => {
  // No import statement needed; query comes from server/utils/db.ts
  return await query('SELECT * FROM users')
})

The context requirement. Many Nuxt composables depend on the Nuxt instance being available. useRuntimeConfig(), useNuxtApp(), and useState() must be called synchronously within a Vue setup function, a Nuxt plugin, or route middleware . Calling them outside these contexts—or after an await without the compiler transform—throws “Nuxt instance is unavailable.” This is not a bug but a safety mechanism: it prevents cross-request state pollution during server rendering, where one user’s request could otherwise leak data into another’s.

// ❌ BREAKING: calling a Nuxt composable outside a valid context
const config = useRuntimeConfig() // Error: Nuxt instance unavailable

// ✅ WORKING: composable called inside setup
export const useMyFeature = () => {
  const config = useRuntimeConfig() // Valid: called within setup context
  return config.public.apiBase
}

Explicit imports when needed. Every auto-import is also available through the #imports alias for cases where explicitness improves clarity . This is optional; the auto-import behavior remains unchanged.

Complete Example Session

// ============================================
// PART 1: LOCAL MODULE STRUCTURE
// ============================================
// modules/
// ├── analytics/
// │   ├── index.ts                    → Module definition
// │   └── runtime/
// │       ├── api/
// │       │   └── track.post.ts       → Server handler
// │       └── app/
// │           └── components/
// │               └── AnalyticsBadge.vue
// └── seo.ts                          → Single-file module


// ============================================
// PART 2: MODULE DEFINITION
// ============================================
// modules/analytics/index.ts
import { addComponentsDir, addServerHandler, createResolver, defineNuxtModule } from 'nuxt/kit'

export default defineNuxtModule({
  meta: { name: 'analytics' },
  setup() {
    const resolver = createResolver(import.meta.url)

    // Register POST /api/track
    addServerHandler({
      route: '/api/track',
      handler: resolver.resolve('./runtime/api/track.post')
    })

    // Register components from runtime/app/components with prefix
    addComponentsDir({
      path: resolver.resolve('./runtime/app/components'),
      pathPrefix: true
    })
  }
})


// ============================================
// PART 3: MODULE SERVER HANDLER
// ============================================
// modules/analytics/runtime/api/track.post.ts
export default defineEventHandler(async (event) => {
  // readBody parses the JSON payload
  const body = await readBody(event)

  // Validate required fields
  if (!body.event) {
    throw createError({ statusCode: 400, message: 'Event name required' })
  }

  // In production, this would write to an analytics database
  console.log(`[analytics] ${body.event}`, body.properties || {})

  return { tracked: true }
})


// ============================================
// PART 4: MODULE COMPONENT
// ============================================
// modules/analytics/runtime/app/components/AnalyticsBadge.vue
<template>
  <span class="analytics-badge">Analytics Active</span>
</template>

<style scoped>
.analytics-badge {
  font-size: 12px;
  color: #22c55e;
}
</style>


// ============================================
// PART 5: SERVER MIDDLEWARE
// ============================================
// server/middleware/request-logger.ts
export default defineEventHandler((event) => {
  // Runs for every request before any handler
  // Does NOT return a value, so request continues
  const start = Date.now()
  event.context.startTime = start
})


// ============================================
// PART 6: SERVER UTILITY (AUTO-IMPORTED)
// ============================================
// server/utils/response.ts
export const success = <T>(data: T) => ({ ok: true, data })
export const failure = (message: string) => ({ ok: false, error: message })


// ============================================
// PART 7: API ROUTE USING SERVER UTILITY
// ============================================
// server/api/status.get.ts
export default defineEventHandler(() => {
  // success is auto-imported from server/utils/response.ts
  return success({ status: 'healthy', timestamp: Date.now() })
})


// ============================================
// PART 8: APP COMPOSABLE (AUTO-IMPORTED)
// ============================================
// app/composables/useAnalytics.ts
export const useAnalytics = () => {
  // $fetch is auto-imported from Nuxt
  const track = async (event: string, properties?: Record<string, unknown>) => {
    await $fetch('/api/track', {
      method: 'post',
      body: { event, properties }
    })
  }

  return { track }
}


// ============================================
// PART 9: PAGE USING EVERYTHING
// ============================================
// app/pages/index.vue
<script setup lang="ts">
// useAnalytics is auto-imported from app/composables/
const { track } = useAnalytics()

// useFetch is auto-imported; status comes from server/api/status.get.ts
const { data: status } = await useFetch('/api/status')
</script>

<template>
  <div>
    <AnalyticsBadge />
    <p>Server status: {{ status?.data?.status }}</p>
    <button @click="track('page_view')">Track View</button>
  </div>
</template>


// ============================================
// PART 10: NUXT CONFIG
// ============================================
// nuxt.config.ts
export default defineNuxtConfig({
  // Local modules from modules/ are auto-registered; no listing needed
  // Only distributed modules go here
  modules: [],
  compatibilityDate: '2025-01-01'
})

The ten parts demonstrate how modules, server rules, and auto-imports cooperate. The analytics module registers a server handler and a component. The server utility in server/utils/ is auto-imported into the API route. The app composable is auto-imported into the page. No explicit imports connect these pieces—the conventions do.

Quick Reference

Module Registration Patterns

Pattern	Location	Registration
Local module (directory)	`modules/name/index.ts`	Auto-registered
Local module (file)	`modules/name.ts`	Auto-registered
Distributed module	npm package	Listed in `nuxt.config.ts`
Module with options	Array form	`['@scope/name', { opt: value }]`
Disable inherited module	Config key	`{ moduleName: false }`

Nitro Execution Rules

Component	Location	When It Runs	Per-Request?
Server middleware	`server/middleware/`	Every HTTP request	Yes
Nitro plugin	`server/plugins/`	Server startup	No
API route	`server/api/`	Matching request	Yes
Route middleware	`app/middleware/`	Vue navigation	No

Auto-Import Directories

Directory	Context	Scanned
`app/composables/`	Client + SSR	Top level only
`app/utils/`	Client + SSR	Top level only
`app/components/`	Client + SSR	Recursively
`server/utils/`	Server only	Top level

Auto-Import Pitfalls and Fixes

Symptom	Cause	Fix
`Nuxt instance is unavailable`	Composable called outside context	Call within setup, plugin, or middleware
Nested composable not found	File in subdirectory	Re-export from index or configure `imports.dirs`
Auto-import missing in `.ts` file	Not in scanned directory	Move to `composables/` or `utils/`
Production bundle includes unused code	`imports.autoImport: false` not set	Set `imports.autoImport: false` to disable entirely

Best Practices

✅ Do This:

// Place local modules in modules/ for auto-registration
// modules/auth.ts — no config entry needed                                    // ✅

// Use createResolver for all module paths
const resolver = createResolver(import.meta.url)                              // ✅

// Return objects from API handlers for typed routes
return { users: [] }                                                          // ✅

// Call Nuxt composables synchronously in setup
const config = useRuntimeConfig()                                             // ✅

// Re-export nested composables from index.ts
export { useNested } from './nested/useNested'                                // ✅

// Prefix module components to avoid collisions
addComponentsDir({ path: '...', pathPrefix: true })                           // ✅

❌ Don’t Do This:

// Manually list local modules in nuxt.config
modules: ['./modules/auth']                                                   // ❌

// Hardcode paths relative to process.cwd()
handler: './runtime/handler'                                                  // ❌

// Use res.end() which disables type generation
res.end(JSON.stringify(data))                                                 // ❌

// Call composables after await without compiler transform
await something(); const config = useRuntimeConfig()                          // ❌

// Expect nested composables to auto-import without config
// app/composables/nested/helper.ts — not scanned                             // ❌

// Return a value from server middleware unless terminating
return { blocked: true }                                                      // ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Module runtime files not type-checked	Placed outside `runtime/app/`	Mirror app structure inside `runtime/app/`
Local module runs out of order	Alphabetical execution	Prefix with numbers: `1.auth/`
`useRuntimeConfig` fails after await	Lost Nuxt context	Use `asyncContext` experimental or restructure
Server utility not found in handler	File not in `server/utils/`	Move utility or import explicitly
Auto-import missing after file creation	Dev server not restarted	Restart `nuxt dev` or run `nuxt prepare`
Module component name collides	No prefix set	Enable `pathPrefix: true` in `addComponentsDir`
Nitro plugin runs per-request in serverless	Cold start behavior	Plugins run on boot; not per-request

Real-World Examples

1. Module Adding a Server Route

// modules/health/index.ts
addServerHandler({
  route: '/api/health',
  handler: resolver.resolve('./runtime/health.get')
})

2. Module Adding a Composable

// modules/auth/index.ts
addImportsDir(resolver.resolve('./runtime/app/composables'))

3. Server Middleware for Auth

// server/middleware/auth.ts
export default defineEventHandler((event) => {
  event.context.user = verifyToken(getHeader(event, 'authorization'))
})

4. Nitro Plugin for Database

// server/plugins/db.ts
export default defineNitroPlugin(() => {
  // Runs once at server startup
  connectDatabase()
})

5. Auto-Imported Server Utility

// server/utils/format.ts
export const formatDate = (d: Date) => d.toISOString().split('T')[0]

6. Auto-Imported App Composable

// app/composables/useTheme.ts
export const useTheme = () => useState('theme', () => 'light')

7. Typed Fetch from API Route

// app/pages/stats.vue
const { data } = await useFetch('/api/status')
// data.value is typed based on the handler's return

8. Disabling an Inherited Module

// nuxt.config.ts
export default defineNuxtConfig({
  image: false  // Disables @nuxt/image from a layer
})

9. Module with Options

// nuxt.config.ts
modules: [['@nuxtjs/google-fonts', { families: { Inter: true } }]]

10. Explicit Import from #imports

import { useFetch } from '#imports'
// Explicit import when auto-import feels opaque

Visual

Module Execution Order

┌──────────────────────────────────────────────────────────────┐
│  NUXT STARTUP                                                │
│                                                              │
│  1. Load nuxt.config.ts modules                              │
│     ├── ['@nuxtjs/tailwindcss']                              │
│     └── ['@nuxtjs/google-fonts', { ... }]                    │
│                                                              │
│  2. Load local modules from modules/ (alphabetical)          │
│     ├── modules/1.auth/index.ts                              │
│     ├── modules/2.analytics/index.ts                         │
│     └── modules/seo.ts                                       │
│                                                              │
│  3. Each module's setup() runs sequentially                  │
│     ├── auth: addServerHandler, addImportsDir                │
│     └── analytics: addComponentsDir, addServerHandler        │
│                                                              │
│  Modules that run later can depend on earlier modules.       │
│  Numeric prefixes control order within the modules/ dir.     │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Server Request Path with Nitro

┌──────────────────────────────────────────────────────────────┐
│  INCOMING REQUEST                                            │
│                                                              │
│  ┌─────────────────┐                                        │
│  │ Nitro boots     │  (serverless: per cold start)          │
│  │ Runs plugins    │  (server/plugins/)                     │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ Server          │  (server/middleware/)                  │
│  │ middleware      │  Runs on EVERY request                 │
│  │ executes        │                                        │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ Matched route   │  (server/api/ or server/routes/)       │
│  │ handler runs    │  Only for matching path + method       │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ Response        │  Returned object → JSON                │
│  │ serialized      │  TypeScript types generated            │
│  └─────────────────┘                                        │
│                                                              │
│  Route middleware (app/middleware/) is separate:             │
│  it runs during VUE navigation, not for raw API requests.    │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Auto-Import Scanning Boundaries

┌──────────────────────────────────────────────────────────────┐
│  app/                                                        │
│  ├── composables/                                            │
│  │   ├── useFoo.ts          ──►  AUTO-IMPORTED               │
│  │   ├── index.ts           ──►  AUTO-IMPORTED               │
│  │   └── nested/                                             │
│  │       └── useBar.ts      ──►  NOT SCANNED                 │
│  │                              (re-export or configure)     │
│  ├── utils/                                                 │
│  │   └── format.ts         ──►  AUTO-IMPORTED                │
│  └── components/                                             │
│      └── Card.vue          ──►  AUTO-IMPORTED                │
│                                                              │
│  server/                                                     │
│  └── utils/                                                 │
│      └── db.ts             ──►  AUTO-IMPORTED (server only)  │
│                                                              │
│  Scanning is shallow for composables and utils,              │
│  recursive for components.                                   │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Nuxt Context Lifecycle

┌──────────────────────────────────────────────────────────────┐
│  COMPONENT SETUP                                             │
│                                                              │
│  ┌─────────────────┐                                        │
│  │ Vue creates     │                                        │
│  │ component       │                                        │
│  │ instance        │                                        │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ Nuxt sets       │  Global variable tracks nuxtApp        │
│  │ context         │  for synchronous access                │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ setup() runs    │  useRuntimeConfig(), useState(), etc.  │
│  │                 │  are valid HERE                        │
│  └────────┬────────┘                                        │
│           ▼                                                  │
│  ┌─────────────────┐                                        │
│  │ Context unset   │  Same tick                             │
│  │                 │  Later calls: "instance unavailable"   │
│  └─────────────────┘                                        │
│                                                              │
│  This synchronous window prevents cross-request pollution    │
│  during SSR. Each request gets its own context.              │
│                                                              │
└──────────────────────────────────────────────────────────────┘

Summary

Item	Value
Module location	`modules/` at project root, auto-registered
Module API	`defineNuxtModule` from `nuxt/kit`
Module execution	Config modules first, then local in alphabetical order
Server middleware	`server/middleware/`, runs every request
Nitro plugins	`server/plugins/`, runs at server startup
Auto-import composables	`app/composables/`, top-level only
Auto-import components	`app/components/`, recursive
Server auto-imports	`server/utils/`
Context constraint	Composables must be called synchronously in setup
Disable module	Set config key to `false`

Key takeaways:

Modules package framework changes. A local module in modules/ is auto-registered without config. Distributed modules are listed in nuxt.config.ts. Both use defineNuxtModule and run at build time, modifying Nuxt’s internals through hooks and kit utilities.
Module runtime files live in runtime/app/. Components intended for the client go in modules/name/runtime/app/components/, not directly in modules/name/components/. This ensures proper type checking and compilation context.
Nitro middleware runs per-request; plugins run at startup. Server middleware in server/middleware/ executes for every HTTP request. Nitro plugins in server/plugins/ execute once when the server boots. Route middleware in app/middleware/ is a separate system for Vue navigation.
Auto-imports are selective, not global. unimport scans code for identifiers and injects only the imports actually used. Production bundles exclude unused auto-imports, so the ergonomic benefit does not cost bundle size.
The Nuxt context is synchronous. Composables like useRuntimeConfig and useState require the Nuxt instance to be available. This window opens during setup and closes in the same tick. Calling them after an await without the compiler transform breaks context and throws an error.
Local module order is alphabetical. Prefix directory names with numbers (1.auth/, 2.analytics/) to control execution order when modules depend on each other.

Remember: Nuxt’s modules, Nitro rules, and auto-imports share a common philosophy: the file system and directory conventions carry meaning. A file in modules/ is a module without registration. A file in server/middleware/ is middleware without configuration. A file in app/composables/ is available without import. The framework reads these locations and assigns behavior. Understanding where files belong—and the context rules that govern their execution—is more important than memorizing APIs. The APIs exist to manipulate these conventions, not to replace them.

Was this helpful?

Stop using slow, ad-bloated tool sites! 🤮

🔎 Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
✅ Finance (Mortgage, Interest, Inflation)
✅ Tech (Base64, JSON, Dev Suite, IP)
✅ Health (BMI, BMR, TDEE)
✅ Productivity (Timer, Workspace, QR)

⚡️ Fast & Private
🔒 No data leaves your device
💎 100% Free

🔗 Use it now: https://tools.kandz.me
🔖 Bookmark it—you’ll need it later!