Project Setup

Topics

For the first few homeworks, I've setup skeleton projects for you. Eventually you'll have to create your own project from scratch. So… in this set of slides, we'll talk about some things were done to set up homeworks 1 through 3. →

• generating a package.json
• using --save vs --save-dev
• linting / eslint

package.json

package.json is a file that contains metadata about your project. It tells npm

• how to install your project
• how it's published (if it's a public project)
• how it's used as a module
• how to retrieve its dependencies
• etc.
  

There's a very comprehensive page on package.json on npm's site.

package.json for Dependencies

We're using it mainly for dependency management.

• a lot of the data in package.json is used for specifying how your code is imported into another file (what name to use, what the license is, etc.).
• we mostly care about the fact that it helps us download all of our project's dependencies at the correct versions
• instead of installing dependencies manually, one-by-one, we can just npm install .

package.json Format

As the name implies (uh, of course), package.json is actually a json file (no surprise there). How is that different from an object literal again? →

• use double quotes for property names
• values can be a string, number, another object, an array, boolean or null
• (not functions, function calls, expressions that need to be evaluated)

Required Fields in package.json

There are two required properties:

• the short, but descriptive name of your project
  • all lowercase
  • one word, no spaces
  • dashes and underscores allowed
• your project's version in the format of MAJOR.MINOR.PATCH see semver spec
• why? together, these become a unique identifier for your module at a specific version

You'll also get warnings on the following, but everything will work even if you don't have these:

description
repository field

Additional Fields in package.json

Some other data in package.json includes:

• author - name of author
• private - a boolean specifying whether or not to publish publicly
• dependencies - an object of all of the dependencies that your project has, along with their version numbers
• devDependencies - and object of all of the dependencies that are necessary for working on/developing your project (such as testing libraries, build tools)

Example package.json

An example minimal package.json:

{
	"name": "my-site",
	"version": "1.0.0",
	"author": "Joe Versoza",
	"private": true,
	"dependencies": {}
}

Or You Can Generate …

Of course, you don't have to write all of that by hand. You can use npm to create a new one for you! Just run:

npm init

It'll ask you a bunch of questions.

• the default answers are adequate for our purposes
• (so you can just press [ENTER] to go through it

Let's give it a try →

(remember, name is all lowercase with underscores and dashes)

Fields Generated

{
  "name": "projectname",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC"
}

Specifying Dependencies

You can manually specify dependencies. The dependencies property is an object with:

• module names as keys
• version specifiers as values

{
	"name": "foo",
	"version": "1.0.0",
	"dependencies": {
		"request": "^2.44.0"
	}
}

Version Specifiers

A list of example version specifiers is included npm's documentation. Some common ones include:

• version- exact version
• ^version - compatible with version
• >version - greater than version
• 1.2.x - all 1.2.x versions
• * - matches any version

Installing Packages

How do I install the request module? →

npm install request

We could then manually add that to our package.json if it's a dependency of our project… just drop it into the dependency property.

Installing Packages Continued

As we're developing, we may want to keep track of all of the packages/modules that we've installed.

Using the --save flag will add it to your package.json automatically.

npm install request --save

Let's see how that works. →

Dependencies vs Dev Dependencies

There's also a --save-dev flag. This flag saves what you just installed to the devDependencies property.

• dependencies - tracks required libraries and packages for you actual project to be installed and deployed
• devDependencies - dependencies that are only necessary if you're working on or developing a project… what are some examples →
  • linter, like JSHint or ESLint
  • build tools, like grunt or gulp
  • unit test tools, like mocha or jasmine

Speaking of Linters

A linter is a program that performs static analysis on your code to determine if there is any use of suspicious or non-standard language constructs.

Static analysis is the inspection of the text of your program without actually executing it.

As you know, the linter that we're using is ESLint. What are some issues that it reports on that could potentially lead to errors? →

• === vs ==
• variables declared without var
• the absence (or presence) of semicolons
• etc.

Linter Features

So, linters have actually moved beyond just detecting potential problems/errors in code. They also can: →

• check for adherence to stylistic conventions
  • (such as line length, camel-case, indentation, etc.)
• report on cyclomatic complexity
  • …a software metric that measures that amount of linearly independent paths through your code
  • basically, how complex your code is

Linter History / For Other Languages

lint was actually the name of a program that would check your C code for potential errors (errors such as dividing by zero, using variables before they're set, etc.).

Of course, linters are no longer just for C. There are linters for other languages (and pretty popular with dynamically typed languages as well):

• Java - SonarQube for code quality inspection
• Python - pylint and pyflakes
• JavaScript … →

JavaScript Linters

There are a actually a bunch of linters for JavaScript, not just ESLint:

• ESLint - highly configurable linter for ES5 and ES6, reports on both potential code issues as well as adherance to stylistic conventions
• JSHint - community driven fork of JSLint, pretty relaxed default configuration, reports on cyclomatic complexity, shifting away from style suggestions
• JSLint - oldest, most opinionated, and non-configurable (but created by the author of the classic JS book, JavaScript the Good Parts, Douglas Crockford)

The trend seems to be shifting towards ESLint in the last year (argh, JavaScript fatigue is real).

ESLint

You can install ESLint through npm (of course).

npm install eslint --save-dev

• See the full installation instructions
• For integration with various editors, check out ESLint's install page
• For example, it works on the commandline, with vim, with atom, with SublimeText →