Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up

🖥 New Vue/Nuxt website for cdnjs.com - The #1 free and open source CDN built to make life easier for developers.

License

NotificationsYou must be signed in to change notification settings

cdnjs/static-website

Repository files navigation

< cdnjs >

The #1 free and open source CDN built to make life easier for developers.


cdnjs Website

Welcome to the cdnjs/static-website repository, the home of the new cdnjs website built with Vue &Nuxt, following the new cdnjs branding proposal fromcdnjs/brand.

This website relies completely on the cdnjs API to operate, resulting in very low resource usage toserve the site and limited app logic to update data being used (only sitemaps have to be updated,everything else uses API calls when a page is loaded).

Getting Started

This project runs onNode.js. Please make sure you have a version installedthat matches our defined requirement in the.nvmrc file for this project.

Included with this project is a dependency lock file. This is used to ensure that all installationsof the project are using the same version of dependencies for consistency.

You can install the Node dependencies following this lock file by running:

npm ci

Once the dependencies are installed, the website is ready to run in development mode. To start Nuxtin development mode (without a custom server), run:

npm run dev

Development in Windows

Before runningnpm run dev, add a global npm package to resolve the'NODE_ENV' is not recognized as an internal or external command issue:

npm install -g win-node-env

Analyzing Bundle

The website is build using Nuxt and relies on Webpack to generate the client-side bundle used torender the site and provide interactivity. Due to this, we can use Webpack's analyzer to betterunderstand what is contributing to the size of the final bundle.

To run the analyzer, use the following package script:

npm run dev:analyze

Environment Variables

Site Base

When working with the site in development, usingnpm run dev ornpm run dev:analyze, theSITE_HOST environment variable will be automatically set to behttp://localhost:3000/, as thisis where the site is made accessible by the dev script.

When deploying this site to production using thenpm run build andnpm run start scripts, theSITE_HOST environment variable must be set and should be the canonical base for where the sitewill be hosted. In production for us, this is set tohttps://cdnjs.com/.

Google Analytics

To enable Google Analytics for a deployment of the site, you should set theGA_ID environmentvariable. This should be set to the unique Google Analytics ID for your property, in the formUA-xxxxxxxxx-x.

Google Analytics is bundled with the site using the@nuxtjs/google-analytics module. If theenvironment variable is not specified, Google Analytics will not be bundled with the deployment.

Sentry Error Logging

To enable basic Sentry error logging, theSENTRY_DSN environment variable must be set with a validDSN URL from Sentry.

To enable source maps & release tracking for error reporting in production, theSENTRY_ORG andSENTRY_PROJECT environment variables must be set with the correct Sentry project information, aswell asSENTRY_AUTH_TOKEN being set to a valid auth token from Sentry. Source maps are used as inproduction we use minified, bundled JavaScript, so the sourcemaps allow Sentry to show where anerror originated from in the source code.

Disallow in robots.txt

By default, during the build process arobots.txt file will be generated for the site that hasUser-agent: * andAllow: *. If you wish to have a more private instance of the site or want toprevent potential SEO contamination, you can set theROBOTS_DISALLOW env var to be1. This willchange theAllow: * rule to beDisallow: /.

Sitemap generation

To enable sitemap generation for the site,NODE_ENV must be set toproduction. This will enablethe initial sitemap generation during build as well as the background task for regenerating thesitemap duringnpm run start, every 30 minutes.

Further, by havingNODE_ENV=production, this will also tell therobots.txt generation script,referenced above, to include a rule pointing to the sitemap index file, based on the providedSITE_HOST env var.

(Note that fornpm run dev:analyze,npm run build &npm run start,NODE_ENV will beautomatically set toproduction).

Production Deployment

To deploy this website to production, the following steps should be taken:

  • Install dependencies withnpm ci
  • Build the site for production withnpm run build
  • Start the custom Express server withnpm run start

For deployments to some PaaS hosts, the installation of dependencies and building the app willautomatically be done, withnpm run start being defined in theProcfile.

To change the port that the app binds to, set thePORT environment var when running the script.

The custom Express server is used to handle our sitemaps, as we have too many routes for Nuxt'ssitemap offering to handle reliably. During the build step (npm run build) initial sitemaps willbe generated. The Express server will then regenerate these every 30 minutes using the cdnjs API. Alog containing the outcome of the last generation in Express is available at/sitemap-log.txt onthe website.

Linting

Our full set of tests for linting can be run at any time with:

npmtest

Included in this repository are aneslint config file as well as asass-lint config file to help with ensuring a consistent style in the codebase forthe JS/Vue and SCSS used in the app.

To help enforce this, we use both eslint and sass-lint in our testing. To run eslint at any time,which checks the code style of any JavaScript and Vue files, you can use:

npm run test:eslint

eslint also provides automatic fixing capabilities, these can be run against the codebase with:

npm run test:eslint:fix

Similarly, sass-lint can be run at any time to check the quality of all the SCSS files used in theapp, by running:

npm run test:scss

A secondary package, sass-lint-auto-fix, is available to help with automatically fixing some of theerrors raised by sass-lint, which can be run with:

npm run test:scss:fix

Like withnpm test, which runs both eslint & sass-lint, a shorter package script is available toautomatically attempt to fix issues from both linting packages, which can be used by running:

npm run test:fix

[8]ページ先頭

©2009-2025 Movatter.jp