static website
1.0.0
Bienvenue dans le référentiel CDNJS / Static-Website, la maison du nouveau site Web CDNJS construit avec Vue & Nuxt, suivant la nouvelle proposition de marque CDNJS de CDNJS / Brand.
Ce site Web s'appuie entièrement sur l'API CDNJS pour fonctionner, ce qui entraîne une très faible utilisation des ressources pour servir le site et une logique d'application limitée pour mettre à jour les données utilisées (seuls les sitemaps doivent être mis à jour, tout le reste utilise des appels d'API lorsqu'une page est chargée).
Ce projet fonctionne sur node.js. Veuillez vous assurer que vous avez installé une version qui correspond à notre exigence définie dans le fichier .nvmrc pour ce projet.
Ce projet est un fichier de verrouillage de dépendance. Ceci est utilisé pour garantir que toutes les installations du projet utilisent la même version de dépendances pour la cohérence.
Vous pouvez installer les dépendances de nœud suivant ce fichier de verrouillage en exécutant:
npm ciUne fois les dépendances installées, le site Web est prêt à s'exécuter en mode développement. Pour démarrer Nuxt en mode développement (sans serveur personnalisé), exécutez:
npm run dev Avant d'exécuter npm run dev , ajoutez un package NPM global pour résoudre le 'NODE_ENV' is not recognized as an internal or external command :
npm install -g win-node-envLe site Web est créé à l'aide de Nuxt et s'appuie sur WebPack pour générer le bundle côté client utilisé pour rendre le site et fournir une interactivité. Pour cette raison, nous pouvons utiliser l'analyseur de WebPack pour mieux comprendre ce qui contribue à la taille du bundle final.
Pour exécuter l'analyseur, utilisez le script de package suivant:
npm run dev:analyze Lorsque vous travaillez avec le site dans le développement, en utilisant npm run dev ou npm run dev:analyze , la variable d'environnement SITE_HOST sera automatiquement définie pour être http://localhost:3000/ , car c'est là que le site est rendu accessible par le script Dev.
Lors du déploiement de ce site en production à l'aide de la npm run build et des scripts npm run start , la variable d'environnement SITE_HOST doit être définie et doit être la base canonique pour l'endroit où le site sera hébergé. En production pour nous, cela est défini sur https://cdnjs.com/ .
Pour activer Google Analytics pour un déploiement du site, vous devez définir la variable d'environnement GA_ID . Cela devrait être défini sur l'ID unique Google Analytics pour votre propriété, sous le formulaire UA-xxxxxxxxx-x .
Google Analytics est regroupé avec le site à l'aide du module @nuxtjs/google-analytics . Si la variable d'environnement n'est pas spécifiée, Google Analytics ne sera pas regroupé avec le déploiement.
Pour activer la journalisation des erreurs de base de base, la variable d'environnement SENTRY_DSN doit être définie avec une URL DSN valide de Sentry.
Pour activer les cartes source et le suivi des versions pour les rapports d'erreurs en production, les variables d'environnement SENTRY_ORG et SENTRY_PROJECT doivent être définies avec les informations du projet Sentry correctes, ainsi que SENTRY_AUTH_TOKEN étant définie sur un jeton d'authentification valide de Sentry. Les cartes source sont utilisées comme dans la production, nous utilisons un JavaScript minifié et groupé, de sorte que les Sourcemaps permettent à Sentry de montrer d'où une erreur est originaire du code source.
Par défaut, pendant le processus de construction, un fichier robots.txt sera généré pour le site qui a User-agent: * et Allow: * . Si vous souhaitez avoir une instance plus privée du site ou si vous souhaitez empêcher la contamination potentielle du référencement, vous pouvez définir le ROBOTS_DISALLOW ENV VAR pour être 1 . Cela modifiera la règle Allow: * à Disallow: / .
Pour activer la génération de sitemap pour le site, NODE_ENV doit être défini sur production . Cela permettra la génération initiale du site du site pendant la construction ainsi que la tâche d'arrière-plan pour régénérer le site de site pendant npm run start , toutes les 30 minutes.
De plus, en ayant NODE_ENV=production , cela indiquera également au script de génération robots.txt , référencé ci-dessus, pour inclure une règle pointant vers le fichier d'index du site, basé sur le SITE_HOST fourni_host env
(Notez que pour npm run dev:analyze , npm run build & npm run start , NODE_ENV sera automatiquement défini sur production ).
Pour déployer ce site Web en production, les étapes suivantes doivent être prises:
npm cinpm run buildnpm run start Pour les déploiements à certains hôtes PaaS, l'installation de dépendances et la création de l'application se feront automatiquement, avec npm run start à être défini dans le Procfile .
Pour modifier le port auquel l'application se lie, définissez l'environnement PORT VAR lors de l'exécution du script.
Le serveur Express personnalisé est utilisé pour gérer nos sitemaps, car nous avons trop d'itinéraires pour l'offre de sitemap de Nuxt pour gérer de manière fiable. Pendant l'étape de construction ( npm run build ), les sitemaps initiaux seront générés. Le serveur express les régénera ensuite toutes les 30 minutes à l'aide de l'API CDNJS. Un journal contenant le résultat de la dernière génération dans Express est disponible sur /sitemap-log.txt sur le site Web.
Notre ensemble complet de tests pour la liaison peut être exécuté à tout moment avec:
npm testCe référentiel comprend un fichier de configuration Eslint ainsi qu'un fichier de configuration Sass-lint pour aider à assurer un style cohérent dans la base de code pour le JS / VUE et les SCS utilisés dans l'application.
Pour aider à l'appliquer, nous utilisons à la fois Eslint et Sass-lint dans nos tests. Pour exécuter Eslint à tout moment, qui vérifie le style de code de tous les fichiers JavaScript et Vue, vous pouvez utiliser:
npm run test:eslintEslint fournit également des capacités de fixation automatique, celles-ci peuvent être exécutées contre la base de code avec:
npm run test:eslint:fixDe même, Sass-lint peut être exécuté à tout moment pour vérifier la qualité de tous les fichiers SCSS utilisés dans l'application, en exécutant:
npm run test:scssUn package secondaire, Sass-lint-auto-fix, est disponible pour aider à réparer automatiquement certaines des erreurs soulevées par Sass-lint, qui peuvent être exécutées avec:
npm run test:scss:fix Comme avec npm test , qui exécute à la fois Eslint et Sass-Lint, un script de package plus court est disponible pour tenter automatiquement de résoudre les problèmes à partir des deux packages de liaison, qui peuvent être utilisés en exécutant:
npm run test:fix
