Utilisation de la spécification de déploiement d'Amplify Hosting pour configurer la sortie de compilation

La spécification de déploiement d'Amplify Hosting est une spécification basée sur un système de fichiers qui définit la structure de répertoire qui facilite les déploiements vers Amplify Hosting. Un framework peut générer cette structure de répertoire attendue en sortie de sa commande de construction, ce qui lui permet de tirer parti des primitives de service d'Amplify Hosting. Amplify Hosting comprend la structure du bundle de déploiement et le déploie en conséquence.

Pour une démonstration vidéo expliquant comment utiliser les spécifications de déploiement, consultez Comment héberger un site Web via AWS Amplify le YouTube canal Amazon Web Services.

Voici un exemple de la structure de dossiers qu'Amplify attend pour le bundle de déploiement. À un niveau élevé, il possède un dossier nomméstatic, un dossier nommé compute et un fichier manifeste de déploiement nommé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

Amplifier SSR le support primitif

La spécification de déploiement d'Amplify Hosting définit un contrat qui correspond étroitement aux primitives suivantes.

Actifs statiques

Fournit des frameworks capables d'héberger des fichiers statiques.

Calcul

Fournit des frameworks capables d'exécuter un HTTP serveur Node.js sur le port 3000.

Optimisation de l'image

Fournit aux frameworks un service permettant d'optimiser les images lors de l'exécution.

Règles de routage

Fournit des frameworks dotés d'un mécanisme permettant de mapper les chemins des demandes entrantes vers des cibles spécifiques.

L'.amplify-hosting/staticannuaire

Vous devez placer dans le .amplify-hosting/static répertoire tous les fichiers statiques accessibles au public destinés à être servis par l'applicationURL. Les fichiers contenus dans ce répertoire sont servis via la primitive static assets.

Les fichiers statiques sont accessibles à la racine (/) de l'application URL sans modification de leur contenu, de leur nom de fichier ou de leur extension. De plus, les sous-répertoires sont conservés dans la URL structure et apparaissent avant le nom du fichier. À titre d'exemple, .amplify-hosting/static/favicon.ico sera servi depuis https://myAppId.amplify-hostingapp.com/favicon.ico et .amplify-hosting/static/_nuxt/main.js sera servi depuis https://myAppId.amplify-hostingapp.com/_nuxt/main.js

Si un framework permet de modifier le chemin de base de l'application, il doit ajouter le chemin de base aux actifs statiques du .amplify-hosting/static répertoire. Par exemple, si le chemin de base est/folder1/folder2, la sortie de génération pour un actif statique appelé main.css sera.amplify-hosting/static/folder1/folder2/main.css.

L'.amplify-hosting/computeannuaire

Une ressource de calcul unique est représentée par un sous-répertoire unique nommé default contenu dans le .amplify-hosting/compute répertoire. Le chemin est.amplify-hosting/compute/default. Cette ressource de calcul correspond à la primitive de calcul d'Amplify Hosting.

Le contenu du default sous-répertoire doit être conforme aux règles suivantes.

• Un fichier doit exister à la racine du default sous-répertoire pour servir de point d'entrée à la ressource de calcul.

• Le fichier du point d'entrée doit être un module Node.js et il doit démarrer un HTTP serveur qui écoute sur le port 3000.

• Vous pouvez placer d'autres fichiers dans le default sous-répertoire et y faire référence à partir du code contenu dans le fichier du point d'entrée.

• Le contenu du sous-répertoire doit être autonome. Le code du module du point d'entrée ne peut référencer aucun module en dehors du sous-répertoire. Notez que les frameworks peuvent regrouper leur HTTP serveur comme ils le souhaitent. Si le processus de calcul peut être lancé avec la node server.js commande, où server.js is est le nom du fichier d'entrée, depuis le sous-répertoire, Amplify considère que la structure du répertoire est conforme à la spécification de déploiement.

Amplify Hosting regroupe et déploie tous les fichiers du default sous-répertoire vers une ressource de calcul provisionnée. Chaque ressource de calcul se voit attribuer 512 Mo de stockage éphémère. Ce stockage n'est pas partagé entre les instances d'exécution, mais est partagé entre les invocations suivantes au sein de la même instance d'exécution. Les instances d'exécution sont limitées à une durée d'exécution maximale de 15 minutes, et le seul chemin accessible en écriture au sein de l'instance d'exécution est le /tmp répertoire. La taille compressée de chaque ensemble de ressources de calcul ne peut pas dépasser 220 Mo. Par exemple, le .amplify/compute/default sous-répertoire ne peut pas dépasser 220 Mo lorsqu'il est compressé.

le fichier .amplify-hosting/deploy-manifest.json ;

Utilisez le deploy-manifest.json fichier pour stocker les détails de configuration et les métadonnées d'un déploiement. Au minimum, un deploy-manifest.json fichier doit inclure un version attribut, l'routesattribut avec une route fourre-tout spécifiée et l'frameworkattribut avec des métadonnées de structure spécifiées.

La définition d'objet suivante illustre la configuration d'un manifeste de déploiement.

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

Les rubriques suivantes décrivent les détails et l'utilisation de chaque attribut du manifeste de déploiement.

Utilisation de l'attribut version

L'versionattribut définit la version de la spécification de déploiement que vous implémentez. Actuellement, la seule version pour la spécification de déploiement d'Amplify Hosting est la version 1. L'JSONexemple suivant illustre l'utilisation de l'versionattribut.

"version": 1

Utilisation de l'attribut routes

L'routesattribut permet aux frameworks de tirer parti de la primitive des règles de routage d'Amplify Hosting. Les règles de routage fournissent un mécanisme permettant d'acheminer les chemins des demandes entrantes vers une cible spécifique du bundle de déploiement. Les règles de routage dictent uniquement la destination d'une demande entrante et sont appliquées une fois que la demande a été transformée par des règles de réécriture et de redirection. Pour plus d'informations sur la façon dont Amplify Hosting gère les réécritures et les redirections, consultez. Utilisation des redirections

Les règles de routage ne réécrivent ni ne transforment la demande. Si une demande entrante correspond au modèle de chemin d'un itinéraire, la demande est acheminée telle quelle vers la cible de l'itinéraire.

Les règles de routage spécifiées dans le routes tableau doivent être conformes aux règles suivantes.

• Un itinéraire fourre-tout doit être spécifié. Un itinéraire fourre-tout possède le /* modèle qui correspond à toutes les demandes entrantes.

• Le routes tableau peut contenir un maximum de 25 éléments.

• Vous devez spécifier un Static itinéraire ou un Compute itinéraire.

• Si vous spécifiez un Static itinéraire, le .amplify-hosting/static répertoire doit exister.

• Si vous spécifiez un Compute itinéraire, le .amplify-hosting/compute répertoire doit exister.

• Si vous spécifiez un ImageOptimization itinéraire, vous devez également spécifier un Compute itinéraire. Cela est nécessaire car l'optimisation des images n'est pas encore prise en charge pour les applications purement statiques.

La définition d'objet suivante illustre la configuration de l'Routeobjet.

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

Le tableau suivant décrit les propriétés de l'Routeobjet.

Clé	Type	Obligatoire	Description
path	Chaîne	Oui	Définit un modèle qui correspond aux chemins des demandes entrantes (à l'exception de la chaîne de requête). La longueur maximale du chemin est de 255 caractères. Un tracé doit commencer par la barre oblique/. Un chemin peut contenir n'importe lequel des caractères suivants : [A-Z], [a-z], [0-9], [_-.*$/~"'@ : +]. Pour la correspondance de modèles, seuls les caractères génériques suivants sont pris en charge : *(correspond à 0 caractères ou plus) Le /* modèle est appelé modèle fourre-tout et correspond à toutes les demandes entrantes.
cible	Cible	Oui	Un objet qui définit la cible vers laquelle acheminer la demande correspondante. Si un Compute itinéraire est spécifié, il ComputeResource doit exister un itinéraire correspondant. Si un ImageOptimization itinéraire est spécifié, imageSettings il doit également être spécifié.
repli	Cible	Non	Objet qui définit la cible vers laquelle se rabattre si la cible d'origine renvoie une erreur 404. Le target type et le fallback type ne peuvent pas être identiques pour un itinéraire spécifique. Par exemple, le repli de Static à n'Staticest pas autorisé. Les solutions de secours ne sont prises en charge que pour les GET demandes qui n'ont pas de corps. Si un corps est présent dans la demande, il sera supprimé lors du repli.

La définition d'objet suivante illustre la configuration de l'Targetobjet.

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

Le tableau suivant décrit les propriétés de l'Targetobjet.

Clé	Type	Obligatoire	Description
sorte	Type cible	Oui	Et enum qui définit le type de cible. Les valeurs valides sont Static, Compute et ImageOptimization.
src	Chaîne	Oui pour Compute Non pour les autres primitives	Chaîne qui indique le nom du sous-répertoire du bundle de déploiement qui contient le code exécutable de la primitive. Valide et obligatoire uniquement pour la primitive Compute. La valeur doit pointer vers l'une des ressources de calcul présentes dans le bundle de déploiement. Actuellement, la seule valeur prise en charge pour ce champ estdefault.
cacheControl	Chaîne	Non	Chaîne qui indique la valeur de l'en-tête Cache-Control à appliquer à la réponse. Valable uniquement pour le Static et les ImageOptimization primitives. La valeur spécifiée est remplacée par des en-têtes personnalisés. Pour plus d'informations sur les en-têtes clients d'Amplify Hosting, consultez. En-têtes personnalisés Note Cet en-tête Cache-Control est uniquement appliqué aux réponses réussies dont le code d'état est défini sur 200 (OK).

La définition d'objet suivante illustre l'utilisation de l'TargetKindénumération.

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

La liste suivante indique les valeurs valides pour l'TargetKindénumération.

Statique

Achemine les demandes vers la primitive des actifs statiques.

Calcul

Achemine les demandes vers la primitive de calcul.

ImageOptimization

Achemine les demandes vers la primitive d'optimisation d'image.

L'JSONexemple suivant illustre l'utilisation de l'routesattribut avec plusieurs règles de routage spécifiées.

"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"
      }
    }
  ]

Pour plus d'informations sur la spécification des règles de routage dans votre manifeste de déploiement, voir Meilleures pratiques pour configurer les règles de routage

Utilisation de l'computeResourcesattribut

L'computeResourcesattribut permet aux frameworks de fournir des métadonnées sur les ressources de calcul allouées. Chaque ressource de calcul doit être associée à un itinéraire correspondant.

La définition d'objet suivante illustre l'utilisation de l'ComputeResourceobjet.

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

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

Le tableau suivant décrit les propriétés de l'ComputeResourceobjet.

Clé	Type	Obligatoire	Description
name	Chaîne	Oui	Spécifie le nom de la ressource de calcul. Le nom doit correspondre au nom du sous-répertoire situé dans le.amplify-hosting/compute directory. Pour la version 1 de la spécification de déploiement, la seule valeur valide estdefault.
environnement d’exécution	ComputeRuntime	Oui	Définit le temps d'exécution de la ressource de calcul provisionnée. Les valeurs valides sont nodejs16.x, nodejs18.x et nodejs20.x.
point d'entrée	Chaîne	Oui	Spécifie le nom du fichier de départ à partir duquel le code sera exécuté pour la ressource de calcul spécifiée. Le fichier doit se trouver dans le sous-répertoire qui représente une ressource de calcul.

Si vous avez une structure de répertoire qui ressemble à la suivante.

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

L'computeResourceattribut JSON for ressemblera à ce qui suit.

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

Utilisation de l' imageSettings attribut

L'imageSettingsattribut permet aux frameworks de personnaliser le comportement de la primitive d'optimisation d'image, qui fournit une optimisation à la demande des images lors de l'exécution.

La définition d'objet suivante illustre l'utilisation de l'ImageSettingsobjet.

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

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

Le tableau suivant décrit les propriétés de l'ImageSettingsobjet.

Clé	Type	Obligatoire	Description
tailles	Numéro []	Oui	Un tableau de largeurs d'image prises en charge.
domains	Chaîne []	Oui	Tableau de domaines externes autorisés pouvant utiliser l'optimisation d'image. Laissez le tableau vide pour autoriser uniquement le domaine de déploiement à utiliser l'optimisation des images.
remotePatterns	RemotePattern[]	Oui	Un tableau de modèles externes autorisés qui peuvent utiliser l'optimisation de l'image. Similaire aux domaines, mais offre un meilleur contrôle avec les expressions régulières (regex).
formats	ImageFormat[]	Oui	Un tableau de formats d'image de sortie autorisés.
minimumCacheTTL	Nombre	Oui	Durée du cache en secondes pour les images optimisées.
dangerouslyAllowSVG	Booléen	Oui	Permet de SVG saisir une imageURLs. Cette option est désactivée par défaut pour des raisons de sécurité.

La définition d'objet suivante illustre l'utilisation de l'RemotePatternobjet.

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

Le tableau suivant décrit les propriétés de l'RemotePatternobjet.

Clé	Type	Obligatoire	Description
protocole ;	Chaîne	Non	Protocole du modèle de télécommande autorisé. Les valeurs valides sont http ou https.
hostname	Chaîne	Oui	Le nom d'hôte du modèle distant autorisé. Vous pouvez spécifier un littéral ou un caractère générique. Un seul `*` correspond à un seul sous-domaine. Un double `**` correspond à un nombre quelconque de sous-domaines. Amplify n'autorise pas les caractères génériques où seul `**` est spécifié.
port	Chaîne	Non	Port du modèle de télécommande autorisé.
chemin d'accès	Chaîne	Non	Le nom du chemin du modèle de télécommande autorisé.

L'exemple suivant illustre l'imageSettingsattribut.

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

Utilisation de l'attribut framework

Utilisez l'frameworkattribut pour spécifier les métadonnées du framework.

La définition d'objet suivante illustre la configuration de l'FrameworkMetadataobjet.

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

Le tableau suivant décrit les propriétés de l'FrameworkMetadataobjet.

Clé	Type	Obligatoire	Description
name	Chaîne	Oui	Le nom du framework.
version	Chaîne	Oui	Version du framework. Il doit s'agir d'une chaîne de version sémantique (semver) valide.

Meilleures pratiques pour configurer les règles de routage

Les règles de routage fournissent un mécanisme pour acheminer les chemins des demandes entrantes vers des cibles spécifiques du bundle de déploiement. Dans un bundle de déploiement, les auteurs du framework peuvent émettre des fichiers vers la sortie de build qui sont déployés sur l'une des cibles suivantes :

• Ressources statiques primitives — Les fichiers sont contenus dans le .amplify-hosting/static répertoire.

• Primitive de calcul — Les fichiers sont contenus dans le .amplify-hosting/compute/default répertoire.

Les auteurs du framework fournissent également un ensemble de règles de routage dans le fichier manifeste de déploiement. Chaque règle du tableau est comparée à la demande entrante dans un ordre séquentiel, jusqu'à ce qu'il y ait une correspondance. Lorsqu'il existe une règle de correspondance, la demande est acheminée vers la cible spécifiée dans la règle de correspondance. Facultativement, une cible de secours peut être spécifiée pour chaque règle. Si la cible d'origine renvoie une erreur 404, la demande est acheminée vers la cible de secours.

La spécification de déploiement exige que la dernière règle de l'ordre de traversée soit une règle fourre-tout. Une règle fourre-tout est spécifiée avec le /* chemin. Si la demande entrante ne correspond à aucune des routes précédentes du tableau de règles de routage, elle est acheminée vers la cible de règles fourre-tout.

Pour SSR des frameworks comme celui-ciNuxt.js, la cible de la règle fourre-tout doit être la primitive de calcul. Cela est dû au fait que SSR les applications ont des pages affichées côté serveur avec des itinéraires qui ne sont pas prévisibles au moment de la création. Par exemple, si une Nuxt.js application possède une page /blog/[slug] où se [slug] trouve un paramètre de route dynamique. La cible de la règle fourre-tout est le seul moyen d'acheminer les demandes vers ces pages.

En revanche, des modèles de trajectoire spécifiques peuvent être utilisés pour cibler des itinéraires connus au moment de la construction. Par exemple, Nuxt.js diffuse les actifs statiques depuis le /_nuxt chemin. Cela signifie que le /_nuxt/* chemin peut être ciblé par une règle de routage spécifique qui achemine les demandes vers la primitive des actifs statiques.

Routage des dossiers publics

La plupart SSR des frameworks offrent la possibilité de servir des actifs statiques mutables à partir d'un public dossier. Les fichiers tels que favicon.ico et robots.txt sont généralement conservés dans le public dossier et sont servis à partir de la racine de l'applicationURL. Par exemple, le favicon.ico fichier est servi à partir dehttps://example.com/favicon.ico. Notez qu'il n'existe aucun modèle de chemin prévisible pour ces fichiers. Ils sont presque entièrement dictés par le nom du fichier. La seule façon de cibler les fichiers contenus dans le public dossier est d'utiliser la méthode fourre-tout. Cependant, la cible de l'itinéraire fourre-tout doit être la primitive de calcul.

Nous recommandons l'une des approches suivantes pour gérer votre public dossier.

1. Utilisez un modèle de chemin pour cibler les chemins de requête contenant des extensions de fichiers. Par exemple, vous pouvez l'utiliser /*.* pour cibler tous les chemins de demande contenant une extension de fichier.

   Notez que cette approche peut être peu fiable. Par exemple, si le public dossier contient des fichiers sans extension, ils ne sont pas visés par cette règle. Un autre problème à prendre en compte avec cette approche est que l'application peut avoir des pages avec des points dans leur nom. Par exemple, une page /blog/2021/01/01/hello.world sera ciblée par la /*.* règle. Ce n'est pas idéal car la page n'est pas un actif statique. Toutefois, vous pouvez ajouter une cible de secours à cette règle pour garantir qu'en cas d'erreur 404 provenant de la primitive statique, la requête revienne à la primitive de calcul.

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

2. Identifiez les fichiers du public dossier au moment de la création et émettez une règle de routage pour chaque fichier. Cette approche n'est pas évolutive car la spécification de déploiement impose une limite de 25 règles.

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

3. Recommandez aux utilisateurs de votre framework de stocker tous les actifs statiques mutables dans un sous-dossier du public dossier.

   Dans l'exemple suivant, l'utilisateur peut stocker tous les actifs statiques modifiables dans le public/assets dossier. Ensuite, une règle de routage avec le modèle de chemin /assets/* peut être utilisée pour cibler tous les actifs statiques mutables du public/assets dossier.

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

4. Spécifiez une solution de secours statique pour l'itinéraire fourre-tout. Cette approche présente des inconvénients qui sont décrits plus en détail dans la Routage de secours fourre-tout section suivante.

Routage de secours fourre-tout

Pour les SSR frameworks tels que ceux Nuxt.js où une route fourre-tout est spécifiée pour la cible primitive de calcul, les auteurs du framework peuvent envisager de spécifier une solution de secours statique pour la route fourre-tout afin de résoudre le problème de routage des dossiers. public Cependant, ce type de règle de routage interrompt les pages 404 affichées côté serveur. Par exemple, si l'utilisateur final visite une page qui n'existe pas, l'application affiche une page 404 avec un code d'état 404. Toutefois, si la route fourre-tout comporte une solution de secours statique, la page 404 n'est pas affichée. Au lieu de cela, la requête revient à la primitive statique et aboutit toujours à un code d'état 404, mais la page 404 n'est pas rendue.

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

Routage du chemin de base

Les frameworks qui offrent la possibilité de modifier le chemin de base de l'application sont censés ajouter le chemin de base aux actifs statiques du .amplify-hosting/static répertoire. Par exemple, si le chemin de base est/folder1/folder2, la sortie de génération pour un actif statique appelé main.css sera.amplify-hosting/static/folder1/folder2/main.css.

Cela signifie que les règles de routage doivent également être mises à jour pour refléter le chemin de base. Par exemple, si le chemin de base est/folder1/folder2, la règle de routage pour les actifs statiques du public dossier sera la suivante.

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

De même, les routes côté serveur doivent également être précédées du chemin de base. Par exemple, si le chemin de base est/folder1/folder2, la règle de routage de l'/apiitinéraire ressemblera à ce qui suit.

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

Cependant, le chemin de base ne doit pas être ajouté à l'itinéraire fourre-tout. Par exemple, si le chemin de base est le suivant/folder1/folder2, l'itinéraire fourre-tout restera le suivant.

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

Exemples de routes Nuxt.js

Voici un exemple de deploy-manifest.json fichier pour une application Nuxt qui montre comment spécifier des règles de routage.

{
  "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"
  }
}

Voici un exemple de deploy-manifest.json fichier pour Nuxt qui montre comment spécifier des règles de routage, y compris des chemins de 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"
  }
}

Pour plus d'informations sur l'utilisation de l'routesattribut, consultezUtilisation de l'attribut routes.