vercel
39.1.0
Développer. Aperçu. Bateau.
Documentation · Changelog · Modèles · CLI
Le Frontend Cloud de Vercel fournit l'expérience et l'infrastructure du développeur pour construire, mettre à l'échelle et sécuriser un Web plus rapide et plus personnalisé.
Commencez par importer un projet, en choisissant un modèle ou en utilisant le Vercel CLI. Ensuite, git push pour déployer.
Pour plus de détails sur la façon d'utiliser Vercel, consultez notre documentation.
Ce projet utilise PNPM pour installer des dépendances et exécuter les scripts.
Vous pouvez utiliser le script vercel pour exécuter des modifications locales comme si vous invitiez Vercel CLI. Par exemple, vercel deploy --cwd=/path/to/project pourrait être exécuté avec des modifications locales avec pnpm vercel deploy --cwd=/path/to/project .
Lorsque vous contribuez à ce référentiel, veuillez d'abord discuter du changement que vous souhaitez apporter via des discussions GitHub avec les propriétaires de ce référentiel avant de soumettre une demande de traction.
Veuillez lire notre code de conduite et le suivre dans toutes vos interactions avec le projet.
Ce projet est configuré dans un monorepo, où un référentiel contient plusieurs packages NPM. Les dépendances sont installées et gérées avec pnpm , et non npm CLI.
Pour commencer, exécutez ce qui suit:
git clone https://github.com/vercel/vercel cd vercel corepack enable pnpm install pnpm build pnpm lint pnpm test-unit
Assurez-vous que tous les tests passent avant d'apporter des modifications.
Vous pouvez utiliser pnpm vercel à partir du package cli pour invoquer Vercel CLI avec des modifications locales:
cd ./packages/cli pnpm vercel <cli-commands...>
Voir le développement local CLI pour plus de détails.
Une fois que vous avez terminé vos modifications (nous vous suggérons même de le faire en cours de route), assurez-vous que tous les tests passent toujours en fonctionnant:
pnpm test-unit
de la racine du projet.
Si un test échoue, assurez-vous de le réparer avec vos modifications. Voir Interprétation des erreurs de test pour plus d'informations sur la façon dont les tests sont exécutés, en particulier les tests d'intégration.
Une fois que vous êtes convaincu que vos modifications fonctionnent correctement, ouvrez une demande de traction sur le référentiel principal.
La demande de traction sera examinée par les responsables et les tests seront vérifiés par notre plate-forme d'intégration continue.
Il existe 2 types de tests dans ce référentiel - tests unitaires et tests d'intégration.
Les tests unitaires sont exécutés localement avec jest et s'exécutent rapidement car ils testent les plus petites unités de code.
Les tests d'intégration créent des déploiements sur votre compte Vercel à l'aide du nom du projet test . Une fois chaque test déployé, la clé probes est utilisée pour vérifier si la réponse est la valeur attendue. Si la valeur ne correspond pas, vous verrez un message expliquant la différence. Si le déploiement n'a pas réussi, vous verrez un message plus générique comme ce qui suit:
[Error: Fetched page https://test-8ashcdlew.vercel.app/root.js does not contain hello Root!. Instead it contains An error occurred with this application. NO_STATUS_CODE_FRO Response headers: cache-control=s-maxage=0 connection=close content-type=text/plain; charset=utf-8 date=Wed, 19 Jun 2019 18:01:37 GMT server=now strict-transport-security=max-age=63072000 transfer-encoding=chunked x-now-id=iad1:hgtzj-1560967297876-44ae12559f95 x-now-trace=iad1]
Dans de tels cas, vous pouvez visiter l'URL de l'échec du déploiement et de l'append /_logs pour voir l'erreur de construction. Dans le cas ci-dessus, ce serait https://test-8ashcdlew.vercel.app/_logs
Les journaux de ce déploiement contiendront l'erreur réelle qui peut vous aider à comprendre ce qui s'est mal passé.
Lors de l'exécution de la suite d'intégration complète localement, il n'est pas recommandé, il est parfois utile d'isoler un test d'échec en l'exécutant sur votre machine. Pour ce faire, vous devrez vous assurer que les informations d'identification appropriées sont obtenues dans votre coquille:
Créez un jeton d'accès. Suivez les insuctions ici https://vercel.com/docs/rest-api#creating-an-access-token. Assurez-vous que la portée des jetons est pour votre compte personnel.
Prenez l'ID d'équipe du tableau de bord Vercel à https://vercel.com/<MY-TEAM>/~/settings ~/settings.
Source-les dans votre fichier shell rc: echo 'export VERCEL_TOKEN=<MY-TOKEN> VERCEL_TEAM_ID=<MY-TEAM-ID>' >> ~/.zshrc
De là, vous devriez pouvoir déclencher un test d'intégration. Choisissez celui qui est déjà isolé pour vérifier que les choses fonctionnent:
cd packages/next
Exécutez le test:
pnpm test test/fixtures/00-server-build/index.test.js
Certains constructeurs utilisent @vercel/nft vers les fichiers d'arborescence avant le déploiement. Si vous soupçonnez une erreur avec ce mécanisme de partage d'arbres, vous pouvez créer le script suivant dans votre projet:
const {nodeFileTrace} = require ('@ vercel / nft'); nodeFileTrace (['path / to / entrypoint.js'], {
ts: vrai,
mixodules: true,})
.Then (o => console.log (o.filelist))
.Then (e => console.error (e));Lorsque vous exécutez ce script, vous verrez tous les fichiers importés. Si les fichiers sont manquants, le bogue est dans @ vercel / nft et non le constructeur.
Parfois, vous souhaitez tester les modifications d'un constructeur par rapport à un projet existant, peut-être avec vercel dev ou un déploiement réel. Vous pouvez éviter de publier chaque changement de constructeur en NPM en téléchargeant le constructeur en tant que tarball.
Changer le répertoire vers le cd ./packages/node
Exécutez pnpm build pour compiler les étapes dactylographiées et autres étapes de construction
Exécutez npm pack pour créer un fichier de tarball
Exécutez vercel *.tgz pour télécharger le fichier de tarball et obtenir une URL
Modifiez tout projet vercel.json existant et remplacez use par l'URL
Exécutez vercel ou vercel dev à déployer avec le constructeur expérimental
Code de conduite
Lignes directrices contributives
Licence Apache 2.0
