Uso de la especificación de implementación de Amplify Hosting para configurar la salida de la compilación

La especificación de implementación de Amplify Hosting es una especificación basada en un sistema de archivos que define la estructura de directorios que facilita las implementaciones en Amplify Hosting. Un marco puede generar esta estructura de directorios prevista como resultado de su comando de compilación, lo que permite que el marco utilice los elementos primitivos de servicio de Amplify Hosting. Amplify Hosting entiende la estructura del paquete de implementación y lo implementa como corresponde.

Para ver una demostración en vídeo en la que se explica cómo utilizar la especificación de despliegue, consulte Cómo alojar cualquier sitio web mediante AWS Amplify el YouTube canal Amazon Web Services.

A continuación se incluye un ejemplo de la estructura de carpetas que Amplify espera para el paquete de implementación. En un nivel superior, tiene una carpeta denominada static, una carpeta denominada compute y un archivo de manifiesto de implementación denominado deploy-manifest.json.

.amplify-hosting/
├── compute/
│   └── default/
│       ├── chunks/
│       │   └── app/
│       │       ├── _nuxt/
│       │       │   ├── index-xxx.mjs
│       │       │   └── index-styles.xxx.js
│       │       └── server.mjs
│       ├── node_modules/
│       └── server.js
├── static/
│   ├── css/
│   │   └── nuxt-google-fonts.css
│   ├── fonts/
│   │   ├── font.woff2
│   ├── _nuxt/
│   │   ├── builds/
│   │   │   └── latest.json
│   │   └── entry.xxx.js
│   ├── favicon.ico
│   └── robots.txt
└── deploy-manifest.json

Amplify SSR el soporte primitivo

La especificación de implementación de Amplify Hosting define un contrato que se corresponde estrechamente con los siguientes elementos primitivos.

Activos estáticos

Proporciona a los marcos la capacidad de alojar archivos estáticos.

Cálculo

Proporciona marcos con la capacidad de ejecutar un HTTP servidor Node.js en el puerto 3000.

Optimización de imágenes

Proporciona a los marcos un servicio para optimizar las imágenes en tiempo de ejecución.

Reglas de enrutamiento

Proporciona a los marcos un mecanismo para asignar las rutas de las solicitudes entrantes a destinos específicos.

El directorio .amplify-hosting/static

Debe colocar en el .amplify-hosting/static directorio todos los archivos estáticos de acceso público que estén destinados a ser servidos desde la aplicaciónURL. Los archivos de este directorio se distribuyen a través del elemento primitivo de activos estáticos.

Se puede acceder a los archivos estáticos en la raíz (/) de la aplicación URL sin ningún cambio en su contenido, nombre de archivo o extensión. Además, los subdirectorios se conservan en la URL estructura y aparecen antes del nombre del archivo. Por ejemplo, .amplify-hosting/static/favicon.ico se distribuirá desde https://myAppId.amplify-hostingapp.com/favicon.ico y .amplify-hosting/static/_nuxt/main.js se distribuirá desde https://myAppId.amplify-hostingapp.com/_nuxt/main.js.

Si un marco admite la posibilidad de modificar la ruta base de la aplicación, debe anteponer la ruta base a los activos estáticos del directorio .amplify-hosting/static. Por ejemplo, si la ruta base es /folder1/folder2, la salida de la compilación de un activo estático llamado main.css será .amplify-hosting/static/folder1/folder2/main.css.

El directorio .amplify-hosting/compute

Un único recurso de computación se representa mediante un único subdirectorio denominado default que se incluye en el directorio .amplify-hosting/compute. La ruta es .amplify-hosting/compute/default. Este recurso de computación se asigna al elemento primitivo de computación de Amplify Hosting.

El contenido del subdirectorio default debe cumplir con las siguientes reglas.

• Debe existir un archivo en la raíz del subdirectorio default para que sirva como punto de entrada al recurso de computación.

• El archivo de punto de entrada debe ser un módulo Node.js y debe iniciar un HTTP servidor que escuche en el puerto 3000.

• Puede colocar otros archivos en el subdirectorio default y hacer referencia a ellos desde el código en el archivo de punto de entrada.

• El contenido del subdirectorio debe ser independiente. El código del módulo de punto de entrada no puede hacer referencia a ningún módulo de fuera del subdirectorio. Tenga en cuenta que los marcos pueden agrupar su HTTP servidor de la forma que deseen. Si el proceso de computación se puede iniciar con el comando node server.js, donde server.js is es el nombre del archivo de entrada, desde el subdirectorio, Amplify considera que la estructura del directorio se ajusta a la especificación de implementación.

Amplify Hosting agrupa e implementa todos los archivos del subdirectorio default en un recurso de computación aprovisionado. Se asignan 512 MB de almacenamiento efímero a cada recurso de computación. Este almacenamiento no se comparte entre las instancias de ejecución, sino que se comparte entre las invocaciones posteriores de la misma instancia de ejecución. Las instancias de ejecución están limitadas a un tiempo máximo de ejecución de 15 minutos y la única ruta en la que se puede escribir dentro de la instancia de ejecución es el directorio /tmp. El tamaño comprimido de cada paquete de recursos de computación no puede superar los 220 MB. Por ejemplo, el subdirectorio .amplify/compute/default no puede superar los 220 MB cuando está comprimido.

El archivo .amplify-hosting/deploy-manifest.json

Utilice el archivo deploy-manifest.json para almacenar los detalles de configuración y los metadatos de una implementación. Como mínimo, un archivo deploy-manifest.json debe incluir un atributo version, el atributo routes con una ruta de método catch-all especificada y el atributo framework con los metadatos del marco especificados.

En la siguiente definición de objeto se muestra la configuración de un manifiesto de implementación.

type DeployManifest = {
  version: 1;
  routes: Route[];
  computeResources?: ComputeResource[];
  imageSettings?: ImageSettings;
  framework: FrameworkMetadata;
};

En los temas siguientes se describen los detalles y el uso de cada atributo del manifiesto de implementación.

Uso del atributo version

El atributo version define la versión de la especificación de implementación que se está implementando. Actualmente, la única versión para la especificación de implementación de Amplify Hosting es la versión 1. El siguiente JSON ejemplo demuestra el uso del version atributo.

"version": 1

Uso del atributo routes

El atributo routes permite a los marcos utilizar el elemento primitivo de reglas de enrutamiento de Amplify Hosting. Las reglas de enrutamiento proporcionan un mecanismo para enrutar las rutas de solicitudes entrantes a un destino específico del paquete de implementación. Las reglas de enrutamiento solo dictan el destino de una solicitud entrante y se aplican después de que las reglas de reescritura y redireccionamiento hayan transformado la solicitud. Para obtener más información sobre cómo Amplify Hosting gestiona las reescrituras y los redireccionamientos, consulte Uso de redireccionamientos.

Las reglas de enrutamiento no reescriben ni transforman la solicitud. Si una solicitud entrante coincide con el patrón de ruta de una ruta, la solicitud se enruta tal cual al destino de la ruta.

Las reglas de enrutamiento especificadas en la matriz routes deben cumplir con las siguientes reglas.

• Se debe especificar una ruta de método catch-all. Una ruta de método catch-all tiene el patrón /* que coincide con todas las solicitudes entrantes.

• La matriz routes puede contener un máximo de 25 elementos.

• Debe especificar una ruta Static o una ruta Compute.

• Si especifica una ruta Static, el directorio .amplify-hosting/static debe existir.

• Si especifica una ruta Compute, el directorio .amplify-hosting/compute debe existir.

• Si especifica una ruta ImageOptimization, también debe especificar una ruta Compute. Es necesario hacerlo porque la optimización de imágenes aún no es compatible con aplicaciones puramente estáticas.

En la siguiente definición de objeto se muestra la configuración del objeto Route.

type Route = {
  path: string;
  target: Target;
  fallback?: Target;
}

En la siguiente tabla se describen las propiedades del objeto Route.

Clave	Tipo	Obligatorio	Descripción
ruta	Cadena	Sí	Define un patrón que coincide con las rutas de las solicitudes entrantes (excepto la cadena de consulta). La longitud máxima de la ruta es de 255 caracteres. Una ruta debe empezar por la barra diagonal /. Una ruta puede contener cualquiera de los siguientes caracteres: [A-Z], [a-z], [0-9], [_-.*$/~"'@:+]. En el caso de la coincidencia de patrones, solo se admiten los siguientes caracteres comodín: * (coincide con 0 o más caracteres). El patrón /* se denomina patrón de método catch-all y coincidirá con todas las solicitudes entrantes.
destino	Destino	Sí	Objeto que define el destino al que se debe enrutar la solicitud coincidente. Si se especifica una ruta Compute, debe existir un objeto ComputeResource correspondiente. Si se especifica una ruta ImageOptimization, también se debe especificar imageSettings.
fallback	Destino	No	Objeto que define el destino de reserva si el destino original devuelve un error 404. El tipo target y el tipo fallback no pueden ser iguales para una ruta específica. Por ejemplo, no se permite una acción de reserva de Static a Static. Las copias alternativas solo se admiten para GET las solicitudes que no tienen cuerpo. Si hay un cuerpo en la solicitud, se eliminará durante la acción de reserva.

En la siguiente definición de objeto se muestra la configuración del objeto Target.

type Target = {
  kind: TargetKind;
  src?: string;
  cacheControl?: string;
}

En la siguiente tabla se describen las propiedades del objeto Target.

Clave	Tipo	Obligatorio	Descripción
kind	Targetkind	Sí	enum que define el tipo de destino. Los valores válidos son Static, Compute y ImageOptimization.
src	Cadena	Sí para Compute No para otros elementos primitivos	Cadena que especifica el nombre del subdirectorio en el paquete de implementación que contiene el código ejecutable del elemento primitivo. Válido y obligatorio solo para el elemento primitivo Compute. El valor debe apuntar a uno de los recursos de computación presentes en el paquete de implementación. En la actualidad, el único valor que se admite para este campo es default.
cacheControl	Cadena	No	Cadena que especifica el valor del encabezado Cache-Control que se va a aplicar a la respuesta. Válido solo para las versiones estáticas y ImageOptimization primitivas. Los encabezados personalizados anulan el valor especificado. Para obtener más información sobre los encabezados de cliente de Amplify Hosting, consulte Encabezados personalizados. nota Este encabezado de Cache-Control solo se aplica a las respuestas correctas con un código de estado establecido en 200 (OK).

En la siguiente definición de objeto se muestra el uso de la enumeración TargetKind.

enum TargetKind {
  Static = "Static",
  Compute = "Compute",
  ImageOptimization = "ImageOptimization"
}

En la siguiente lista se especifican los valores válidos de la enumeración TargetKind.

Estático

Enruta las solicitudes al elemento primitivo de activos estáticos.

Cálculo

Enruta las solicitudes al elemento primitivo de computación.

ImageOptimization

Enruta las solicitudes al elemento primitivo de optimización de imágenes.

El siguiente JSON ejemplo muestra el uso del routes atributo con varias reglas de enrutamiento especificadas.

"routes": [
    {
      "path": "/_nuxt/image",
      "target": {
        "kind": "ImageOptimization",
        "cacheControl": "public, max-age=3600, immutable"
      }
    },
    {
      "path": "/_nuxt/builds/meta/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/_nuxt/builds/*",
      "target": {
        "cacheControl": "public, max-age=1, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/_nuxt/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/*.*",
      "target": {
        "kind": "Static"
      },
      "fallback": {
        "kind": "Compute",
        "src": "default"
      }
    },
    {
      "path": "/*",
      "target": {
        "kind": "Compute",
        "src": "default"
      }
    }
  ]

Para obtener más información sobre cómo especificar reglas de enrutamiento en el manifiesto de implementación, consulte Prácticas recomendadas para configurar reglas de enrutamiento.

Uso del computeResources atributo

El atributo computeResources permite a los marcos proporcionar metadatos sobre los recursos de computación aprovisionados. Cada recurso de computación debe tener una ruta correspondiente asociada.

En la siguiente definición de objeto se muestra el uso del objeto ComputeResource.

type ComputeResource = {
  name: string;
  runtime: ComputeRuntime;
  entrypoint: string;
};

type ComputeRuntime = 'nodejs16.x' | 'nodejs18.x' | 'nodejs20.x';

En la siguiente tabla se describen las propiedades del objeto ComputeResource.

Clave	Tipo	Obligatorio	Descripción
name (nombre)	Cadena	Sí	Especifica el nombre del recurso de computación. El nombre debe coincidir con el nombre del subdirectorio que está dentro de .amplify-hosting/compute directory. Para la versión 1 de la especificación de implementación, el único valor válido es default.
tiempo de ejecución	ComputeRuntime	Sí	Define el tiempo de ejecución del recurso de computación aprovisionado. Los valores válidos son nodejs16.x, nodejs18.x y nodejs20.x.
entrypoint	Cadena	Sí	Especifica el nombre del archivo de inicio desde el que se ejecutará el código para el recurso de computación especificado. El archivo debe estar dentro del subdirectorio que representa un recurso de computación.

Si tiene una estructura de directorios con un aspecto similar al siguiente.

.amplify-hosting
|---compute
|   |---default
|       |---index.js

El atributo JSON para el computeResource atributo tendrá el siguiente aspecto.

"computeResources": [
    {
      "name": "default",
      "runtime": "nodejs16.x",
      "entrypoint": "index.js",
    }
  ]

Uso del imageSettings atributo

El atributo imageSettings permite a los marcos personalizar el comportamiento del elemento primitivo de optimización de imágenes, que proporciona una optimización de imágenes bajo demanda en tiempo de ejecución.

En la siguiente definición de objeto se muestra el uso del objeto ImageSettings.

type ImageSettings = {
  sizes: number[];
  domains: string[];
  remotePatterns: RemotePattern[];
  formats: ImageFormat[];
  minumumCacheTTL: number;
  dangerouslyAllowSVG: boolean;
};

type ImageFormat = 'image/avif' | 'image/webp' | 'image/png' | 'image/jpeg';

En la siguiente tabla se describen las propiedades del objeto ImageSettings.

Clave	Tipo	Obligatorio	Descripción
sizes	Number[]	Sí	Matriz de anchos de imagen admitidos.
domains	String[]	Sí	Matriz de dominios externos permitidos que pueden utilizar la optimización de imágenes. Deje la matriz vacía para permitir que solo el dominio de implementación utilice la optimización de imágenes.
remotePatterns	RemotePattern[]	Sí	Matriz de patrones externos permitidos que pueden utilizar la optimización de imágenes. Similar a domains, pero proporciona más control con expresiones regulares (regex).
formats	ImageFormat[]	Sí	Matriz de formatos de imagen de salida permitidos.
minimumCacheTTL	Número	Sí	Duración del almacenamiento en caché en segundos para las imágenes optimizadas.
dangerouslyAllowSVG	Booleano	Sí	Permite SVG introducir una imagenURLs. De forma predeterminada, está deshabilitada por motivos de seguridad.

En la siguiente definición de objeto se muestra el uso del objeto RemotePattern.

type RemotePattern = {
  protocol?: 'http' | 'https';
  hostname: string;
  port?: string;
  pathname?: string;
}

En la siguiente tabla se describen las propiedades del objeto RemotePattern.

Clave	Tipo	Obligatorio	Descripción
protocol	Cadena	No	Protocolo del patrón remoto permitido. Los valores válidos son http o https.
hostname	Cadena	Sí	Nombre de host del patrón remoto permitido. Puede especificar un literal o un comodín. Un carácter único “*” coincide con un único subdominio. Un carácter doble “**” coincide con cualquier cantidad de subdominios. Amplify no permite caracteres comodín generales cuando solo se especifica “**”.
port	Cadena	No	Puerto del patrón remoto permitido.
pathname	Cadena	No	Nombre de ruta del patrón remoto permitido.

En el siguiente ejemplo se muestra el atributo imageSettings.

"imageSettings": { 
    "sizes": [
      100,
      200
    ],
    "domains": [
      "example.com"
    ],
    "remotePatterns": [
      {
        "protocol": "https",
        "hostname": "example.com",
        "port": "",
        "pathname": "/**",
      }
    ],
    "formats": [
      "image/webp"
    ],
    "minumumCacheTTL": 60,
    "dangerouslyAllowSVG": false
  }

Uso del atributo framework

Utilice el atributo framework para especificar los metadatos del marco.

En la siguiente definición de objeto se muestra la configuración del objeto FrameworkMetadata.

type FrameworkMetadata = {
  name: string;
  version: string;
}

En la siguiente tabla se describen las propiedades del objeto FrameworkMetadata.

Clave	Tipo	Obligatorio	Descripción
name (nombre)	Cadena	Sí	Nombre del marco.
versión	Cadena	Sí	Versión del marco. Debe ser una cadena válida de control de versiones semántico (semver).

Prácticas recomendadas para configurar reglas de enrutamiento

Las reglas de enrutamiento proporcionan un mecanismo para enrutar las rutas de solicitudes entrantes a destinos específicos del paquete de implementación. En un paquete de implementación, los autores de marcos pueden enviar archivos a la salida de la compilación que se implementan en cualquiera de los siguientes destinos:

• Elemento primitivo de activos estáticos: los archivos se encuentran en el directorio .amplify-hosting/static.

• Elemento primitivo de computación: los archivos se encuentran en el directorio .amplify-hosting/compute/default.

Los autores de marcos también proporcionan una matriz de reglas de enrutamiento en el archivo de manifiesto de implementación. Cada regla de la matriz se compara con la solicitud entrante en orden de recorrido secuencial hasta que haya una coincidencia. Cuando hay una regla coincidente, la solicitud se enruta al destino especificado en la regla coincidente. De forma opcional, se puede especificar un destino de reserva para cada regla. Si el destino original devuelve un error 404, la solicitud se enruta al destino de reserva.

La especificación de implementación requiere que la última regla del orden de recorrido sea una regla de método catch-all. Se especifica una regla de método catch-all con la ruta /*. Si la solicitud entrante no coincide con ninguna de las rutas anteriores de la matriz de reglas de enrutamiento, la solicitud se enruta al destino de la regla de método catch-all.

Para SSR marcos comoNuxt.js, el objetivo de la regla general tiene que ser la primitiva de cálculo. Esto se debe a que SSR las aplicaciones tienen páginas renderizadas en el lado del servidor con rutas que no son predecibles en el momento de la compilación. Por ejemplo, si una aplicación Nuxt.js tiene una página en /blog/[slug] donde [slug] es un parámetro de ruta dinámica. El destino de la regla de método catch-all es la única forma de enrutar las solicitudes a estas páginas.

Por el contrario, se pueden usar patrones de ruta específicos para dirigirse a rutas conocidas en el momento de la compilación. Por ejemplo, Nuxt.js distribuye activos estáticos desde la ruta /_nuxt. Esto significa que es posible dirigirse a la ruta /_nuxt/* mediante una regla de enrutamiento específica que enrute las solicitudes al elemento primitivo de activos estáticos.

Enrutamiento de carpetas públicas

La mayoría de SSR los marcos ofrecen la capacidad de almacenar activos estáticos mutables desde una public carpeta. Por lo general, robots.txt los archivos se guardan dentro de la public carpeta y se sirven desde la raíz URL de la aplicación. favicon.ico Por ejemplo, el archivo favicon.ico se distribuye desde https://example.com/favicon.ico. Tenga en cuenta que no existe un patrón de ruta predecible para estos archivos. El nombre del archivo los dicta casi en su totalidad. La única forma de dirigirse a los archivos de la carpeta public consiste en utilizar la ruta de método catch-all. Sin embargo, el destino de la ruta de método catch-all debe ser el elemento primitivo de computación.

Recomendamos uno de los siguientes enfoques para administrar la carpeta public.

1. Use un patrón de rutas para dirigirse a las rutas de solicitud que contienen extensiones de archivo. Por ejemplo, se puede utilizar /*.* para dirigirse a todas las rutas de solicitud que contienen una extensión de archivo.

   Tenga en cuenta que este enfoque puede ser poco fiable. Por ejemplo, si hay archivos sin extensiones de archivo en la carpeta public, esta regla no se dirige a ellos. Otro problema que hay que tener en cuenta con este enfoque es que la aplicación podría tener páginas con puntos en los nombres. Por ejemplo, la regla /*.* se dirigirá a una página en /blog/2021/01/01/hello.world. Esto no es lo ideal, ya que la página no es un activo estático. Sin embargo, puede agregar un destino de reserva a esta regla para garantizar que, cuando se produzca un error 404 del elemento primitivo estático, la solicitud utilice el elemento primitivo de computación como reserva.

   {
       "path": "/*.*",
       "target": {
           "kind": "Static"
       },
       "fallback": {
           "kind": "Compute",
           "src": "default"
       }
   }

2. Identifique los archivos de la carpeta public en el momento de la compilación y emita una regla de enrutamiento para cada archivo. Este enfoque no es escalable, ya que la especificación de implementación impone un límite de 25 reglas.

   {
       "path": "/favicon.ico",
       "target": {
           "kind": "Static"
       }
   },
   {
       "path": "/robots.txt",
       "target": {
           "kind": "Static"
       }
   }

3. Recomiende a los usuarios del marco almacenar todos los activos estáticos mutables en una subcarpeta dentro de la carpeta public.

   En el siguiente ejemplo, el usuario puede almacenar todos los activos estáticos mutables dentro de la carpeta public/assets. A continuación, se puede utilizar una regla de enrutamiento con el patrón de ruta /assets/* para dirigirse a todos los activos estáticos mutables de la carpeta public/assets.

   {
       "path": "/assets/*",
       "target": {
           "kind": "Static"
       }
   }

4. Especifique una reserva estática para la ruta de método catch-all. Este enfoque presenta algunos inconvenientes que se describen en más detalle en la siguiente sección Enrutamiento de reserva de método catch-all.

Enrutamiento de reserva de método catch-all

Para SSR marcos comoNuxt.js, por ejemplo, en los que se especifica una ruta general para el objetivo primitivo de cálculo, los autores del marco podrían considerar la posibilidad de especificar una alternativa estática para la ruta general a fin de resolver el problema del enrutamiento de carpetas. public Sin embargo, este tipo de regla de enrutamiento interrumpe las páginas 404 representadas del servidor. Por ejemplo, si el usuario final visita una página que no existe, la aplicación devuelve una página 404 con el código de estado 404. Sin embargo, si la ruta de método catch-all tiene una reserva estática, no se devuelve la página 404. En su lugar, la solicitud utiliza el elemento primitivo estático como reserva y, aun así, termina con un código de estado 404, pero no se devuelve la página 404.

{
    "path": "/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    },
    "fallback": {
        "kind": "Static"
    }
}

Enrutamiento de rutas base

Está previsto que los marcos que ofrecen la posibilidad de modificar la ruta base de la aplicación antepongan la ruta base a los activos estáticos del directorio .amplify-hosting/static. Por ejemplo, si la ruta base es /folder1/folder2, la salida de la compilación de un activo estático llamado main.css será .amplify-hosting/static/folder1/folder2/main.css.

Esto significa que las reglas de enrutamiento también deben actualizarse para reflejar la ruta base. Por ejemplo, si la ruta base es /folder1/folder2, la regla de enrutamiento de los activos estáticos de la carpeta public tendrá el siguiente aspecto.

{
    "path": "/folder1/folder2/*.*",
    "target": {
        "kind": "Static"
    }
}

Del mismo modo, las rutas del servidor también deben tener la ruta base antepuesta. Por ejemplo, si la ruta base es /folder1/folder2, la regla de enrutamiento de la ruta /api tendrá el siguiente aspecto.

{
    "path": "/folder1/folder2/api/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    }
}

Sin embargo, la ruta base no debe anteponerse a la ruta de método catch-all. Por ejemplo, si la ruta base es /folder1/folder2, la ruta de método catch-all seguirá siendo como la siguiente.

{
    "path": "/*",
    "target": {
        "kind": "Compute",
        "src": "default"
    }
}

Ejemplos de rutas de Nuxt.js

A continuación se incluye un archivo deploy-manifest.json de ejemplo para una aplicación de Nuxt en el que se muestra cómo especificar las reglas de enrutamiento.

{
  "version": 1,
  "routes": [
    {
      "path": "/_nuxt/image",
      "target": {
        "kind": "ImageOptimization",
        "cacheControl": "public, max-age=3600, immutable"
      }
    },
    {
      "path": "/_nuxt/builds/meta/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/_nuxt/builds/*",
      "target": {
        "cacheControl": "public, max-age=1, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/_nuxt/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/*.*",
      "target": {
        "kind": "Static"
      },
      "fallback": {
        "kind": "Compute",
        "src": "default"
      }
    },
    {
      "path": "/*",
      "target": {
        "kind": "Compute",
        "src": "default"
      }
    }
  ],
  "computeResources": [
    {
      "name": "default",
      "entrypoint": "server.js",
      "runtime": "nodejs18.x"
    }
  ],
  "framework": {
    "name": "nuxt",
    "version": "3.8.1"
  }
}

A continuación se incluye un archivo deploy-manifest.json de ejemplo para Nuxt en el que se muestra cómo especificar las reglas de enrutamiento, incluidas rutas base.

{
  "version": 1,
  "routes": [
    {
      "path": "/base-path/_nuxt/image",
      "target": {
        "kind": "ImageOptimization",
        "cacheControl": "public, max-age=3600, immutable"
      }
    },
    {
      "path": "/base-path/_nuxt/builds/meta/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/base-path/_nuxt/builds/*",
      "target": {
        "cacheControl": "public, max-age=1, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/base-path/_nuxt/*",
      "target": {
        "cacheControl": "public, max-age=31536000, immutable",
        "kind": "Static"
      }
    },
    {
      "path": "/base-path/*.*",
      "target": {
        "kind": "Static"
      },
      "fallback": {
        "kind": "Compute",
        "src": "default"
      }
    },
    {
      "path": "/*",
      "target": {
        "kind": "Compute",
        "src": "default"
      }
    }
  ],
  "computeResources": [
    {
      "name": "default",
      "entrypoint": "server.js",
      "runtime": "nodejs18.x"
    }
  ],
  "framework": {
    "name": "nuxt",
    "version": "3.8.1"
  }
}

Para obtener más información sobre el uso del atributo routes, consulte Uso del atributo routes.