Bienvenido al Repositorio CDNJS/Website Static, el hogar del nuevo sitio web de CDNJ construido con Vue & Nuxt, siguiendo la nueva propuesta de marca CDNJS de CDNJS/Brand.
Este sitio web se basa completamente en la API de CDNJS para operar, lo que resulta en un uso de recursos muy bajo para servir al sitio y una lógica limitada de aplicaciones para actualizar los datos que se utilizan (solo se deben actualizar los Sitemaps, todo lo demás usa llamadas API cuando se carga una página).
Este proyecto se ejecuta en Node.js. Asegúrese de tener una versión instalada que coincida con nuestro requisito definido en el archivo .NVMRC para este proyecto.
Se incluye con este proyecto un archivo de bloqueo de dependencia. Esto se utiliza para garantizar que todas las instalaciones del proyecto estén utilizando la misma versión de dependencias para consistencia.
Puede instalar las dependencias de nodo siguiendo este archivo de bloqueo ejecutando:
npm ciUna vez que se instalan las dependencias, el sitio web está listo para ejecutarse en modo de desarrollo. Para iniciar NUXT en modo de desarrollo (sin un servidor personalizado), ejecute:
npm run dev Antes de ejecutar npm run dev , agregue un paquete NPM global para resolver el 'NODE_ENV' is not recognized as an internal or external command :
npm install -g win-node-envEl sitio web se compila utilizando Nuxt y se basa en Webpack para generar el paquete del lado del cliente utilizado para representar el sitio y proporcionar interactividad. Debido a esto, podemos usar el analizador de WebPack para comprender mejor qué está contribuyendo al tamaño del paquete final.
Para ejecutar el analizador, use el siguiente script del paquete:
npm run dev:analyze Cuando se trabaja con el sitio en desarrollo, utilizando npm run dev o npm run dev:analyze , la variable de entorno SITE_HOST se establecerá automáticamente para ser http://localhost:3000/ , ya que aquí es donde el sitio está accesible por el script Dev.
Al implementar este sitio para la producción utilizando los scripts de inicio npm run build y npm run start , la variable de entorno SITE_HOST debe estar configurada y debe ser la base canónica para el lugar donde se alojará el sitio. En producción para nosotros, esto se establece en https://cdnjs.com/ .
Para habilitar Google Analytics para una implementación del sitio, debe establecer la variable de entorno GA_ID . Esto debe establecerse en la ID única de Google Analytics para su propiedad, en el formulario UA-xxxxxxxxx-x .
Google Analytics se incluye con el sitio utilizando el módulo @nuxtjs/google-analytics . Si no se especifica la variable de entorno, Google Analytics no se agrupará con la implementación.
Para habilitar el registro de errores básicos de Sentry, la variable de entorno SENTRY_DSN debe establecerse con una URL DSN válida de Sentry.
Para habilitar los mapas de origen y el seguimiento de la versión para informar de errores en la producción, las variables de entorno SENTRY_ORG y SENTRY_PROJECT deben establecerse con la información correcta del proyecto Sentry, así como SENTRY_AUTH_TOKEN establecido en un token de autenticación válido de Sentry. Los mapas de origen se usan como en la producción, utilizamos JavaScript minificado y agrupado, por lo que los SourCeMaps permiten que Sentry muestre de dónde se originó un error en el código fuente.
De manera predeterminada, durante el proceso de compilación se generará un archivo robots.txt para el sitio que tiene User-agent: * y Allow: * . Si desea tener una instancia más privada del sitio o desea evitar la contaminación de SEO potencial, puede establecer el ROBOTS_DISALLOW Env Var para ser 1 . Esto cambiará la regla Allow: * para Disallow: / .
Para habilitar la generación de mapa del sitio para el sitio, NODE_ENV debe establecerse en production . Esto habilitará la generación inicial del mapa del sitio durante la compilación, así como la tarea de fondo para regenerar el mapa del sitio durante npm run start , cada 30 minutos.
Además, al tener NODE_ENV=production , esto también le indicará al script de generación robots.txt , mencionado anteriormente, que incluya una regla que apunta al archivo de índice Sitemap, basado en el sitio de Site_host de SITE_HOST Var.
(Tenga en cuenta que para npm run dev:analyze , npm run build & npm run start , NODE_ENV se establecerá automáticamente en production ).
Para implementar este sitio web en producción, se deben tomar los siguientes pasos:
npm cinpm run buildnpm run start Para las implementaciones en algunos hosts de PAAs, la instalación de dependencias y la construcción de la aplicación se realizará automáticamente, con npm run start a definirse en el Procfile .
Para cambiar el puerto al que vincula la aplicación, configure el entorno de PORT VAR al ejecutar el script.
El servidor Express Custom se utiliza para manejar nuestros mapas de sitios, ya que tenemos demasiadas rutas para que la oferta de mapa del sitio de Nuxt se maneje de manera confiable. Durante el paso de compilación ( npm run build ) se generarán sitios iniciales. El servidor Express regenerará estos cada 30 minutos utilizando la API CDNJS. Un registro que contiene el resultado de la última generación en Express está disponible en /sitemap-log.txt en el sitio web.
Nuestro conjunto completo de pruebas para pelucas se puede ejecutar en cualquier momento con:
npm testEn este repositorio se incluyen un archivo de configuración de Eslint, así como un archivo de configuración SASS-Lint para ayudar a garantizar un estilo consistente en la base de código para el JS/VUE y SCSS utilizado en la aplicación.
Para ayudar a hacer cumplir esto, usamos tanto Eslint como Sass-Lint en nuestras pruebas. Para ejecutar Eslint en cualquier momento, que verifica el estilo de código de cualquier archivo JavaScript y Vue, puede usar:
npm run test:eslintEslint también proporciona capacidades automáticas de fijación, estas se pueden ejecutar contra la base de código con:
npm run test:eslint:fixDel mismo modo, Sass-Lint se puede ejecutar en cualquier momento para verificar la calidad de todos los archivos SCSS utilizados en la aplicación, ejecutando:
npm run test:scssUn paquete secundario, Sass-Lint-Auto-Fix, está disponible para ayudar a solucionar automáticamente algunos de los errores planteados por Sass-Lint, que se pueden ejecutar con:
npm run test:scss:fix Al igual que con npm test , que ejecuta Eslint y Sass-Lint, un script de paquete más corto está disponible para intentar automáticamente solucionar problemas de ambos paquetes de pelusa, que se pueden usar ejecutando:
npm run test:fix