npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

eslint-config-udacity

v2.0.2

Published

Help you automate Udacity Frontend Nanodegree Style Guide styling check at ease!

Downloads

8

Readme

Udacity Frontend Nanodegree Style Guide - JavaScript

READMEs in other languages:

This config checks for Udacity Frontend Nanodegree Style Guide automatically. You can utilise this eslint config to check your projects before submit, or help check if a project meets Udacity Frontend Nanodegree Style Guide as a reviewer.

Get started

readme-instructors

prerequisite

  • Make sure you have a globall Node/NPM or yarn installed. If not, you can download from Nodejs.org and install Node/NPM, or use nvm to manage your Node installation; if NPM has been installed, you can run npm i -g yarn to install yarn globally
  • Make sure there's a package.json under your project root. If not, you can initialise one by running npm init

how to start

First, install these dependencies using NPM:

npm install --save-dev eslint eslint-config-udacity eslint-plugin-import

Using yarn:

yarn add --dev eslint eslint-config-udacity eslint-plugin-import

Then create a .eslintrc.json configuration file under your project root with the following content after you install the dependencies successfully:

{
  "extends": "udacity"
}

You can achieve the same effect by running echo '{ "extends": "udacity" }' > .eslintrc.json under your project root:

Add the following npm lint scripts in your package.json:

{
  ...
  "scripts": {
    "lint": "eslint ./**/*.js",
    ...
  }
}

Where ./**/*js is the glob pattern of the location of your project files that need styling check, it can also be like app/**/*.js to match all *.js files recursively under the /apps folder, src/*.js to match all .js files in the /src folder, or you can even use app/**/*.js src/*.js combining the patterns to match multiple locations of your project.

Run npm run lint, and you should see the lint results!

Others

⚠ This configuration is still not 100% perfect.

Some of the rules can't be covered by this eslint rule. Specifically, they're the following 4 rules, containing one required check and threes' are suggestion. Some of them(like be careful combining closure in DOM operation) are more like code logic lint, which is hard for eslint to check. In these cases, it requires careful manual check still.

Contribution

  1. fork the repo and submit your changes on a new branch
  2. make sure you add tests if you are adding new rules/features, or at least provide reasons for not doing so
  3. make sure the build are all green before you submit a PR
  4. raise a PR

TODOLIST

See TODOLIST.md.

License

MIT