So You’ve Learned HTML, CSS, and JavaScript; Now What? (Part 4)

Understanding the package.json file

Read Part 1 here.

Read Part 2 here.

Read Part 3 here.

This is part 4 in a long series on first-steps for bootcamp grads or solo learners who have invested time into learning HTML, CSS, and JavaScript as a path towards becoming a web developer, but find themselves mired in the alphabet soup of frameworks, deployment tools, performance metrics, data structures, component libraries, and more.

The content of this series will be updated and fleshed out over time, so I’d encourage you to check back to a given piece which did not dive deeply enough into its topic on your first read.

This is for those intrepid individuals seeking to break into a competitive job market with newfound coding skills, but have been unable to approach the inaccessible professional dialogue focusing ever on the shiny pre-requisite-heavy tool of the day or the newest and most irritating means of acronymical truncation of the English language.

So you’ve learned HTML, CSS, and JavaScript; now what?

Start Using That Package Manager

Still not sure what good that npm is for? Take a simple project folder — one which contains an index.html that can be readily opened in browser with no fuss (no build process).

Then open a terminal window. By now you should be handy with these, and you should have both git and node installed on your machine. Navigate inside your project folder in your terminal, and execute the following:

npm init

What happened? If all went well (and it should have, now, for someone who’s terminal game is strong!), your terminal will have walked you through the creation of a package.json file (feel free to just hit “Enter” and accept all the default answers this first time through). This package.json file is one of the most important files of your career, so I strongly recommend taking the time to explore it and understand its role.

Right now, the contents of your package.json file probably look something like this:

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

Most of this is a direct result of what was entered, or not entered, during the setup process after executing npm init. The scripts object details some scripts we can customize for more sophisticated testing, building, and deployment of our projects, but that’s not relevant just yet. The licence, ISC, is just a free licence published by the Internet Software Consortium. If you’re familiar with MIT licenses, it’s functionally equivalent. If you’re not, it essentially makes the code content of this project open source (yay, open source!).

Below is the contents of a slightly more complex, but still simple, example of a package.json file, borrowed (and slightly edited) from Cody Bonney:

{
    "name": "json-lint-express",
    "version": "0.0.1",
    "author": "Cody Bonney <me@codybonney.com>",
    "description": "a simple web server that lints json strings",
    "license": "MIT",
    "scripts": {
        "start": "node ./app.js"
    },
    "dependencies": {
        "express": "~3.4.7",
        "json-lint": "~0.1.0"
    }
}

So, this project has a name, version, description, and license different from our own, obviously; but the important distinctions are (1) “scripts” and (2) “dependencies.”

(1) Cody’s “scripts” section contains a “start” script, which contains a value of “node ./app.js”.

Bleh, confusion.

It’s actually extraordinarily simple, yet it can be difficult to get a straight answer out of the internet on the best of days. What’s happening here is, the author of this project has created a custom script called “start” which s/he can run with the command “npm start” in the terminal while inside their project folder. And what does this command do? Well it executes “node ./app.js”. What does “node ./app.js” do? It uses node to spin up the project served from the app.js file (in contrast to our own project which is served from index.html, but this is not uncommon at all).

In other words, the author has made the decision that, rather than forcing anyone wishing to run this project to type “node ./app.js” in their terminal, they can simply type “npm start” instead.

Simple, right? This scripts section can be used to combine complex commands. You might see something like:

"scripts": {
     "start: "nuxt build && nuxt start",
     "generate: "firebase deploy && nuxt generate"
 },

All we’re doing is setting up a more friendly shorthand for series of commands. You may not know the commands (look em up!), but that really doesn’t matter right now. What matters is the pattern; the why.

(2) Cody’s “dependencies” object references “express” and “json-lint.” This means that Cody’s project depends on these two packages, whatever they are. The project will not run properly if these packages are not installed on the host machine.

Most professional projects and code bases have dependencies; most Github repos contain projects with dependencies. How do developers deal with all of these dependencies which their own computers may or may not be equipped to handle? Node Package Manager to the rescue. There is a universally recognized command, npm install, which, when executed within a terminal window inside a project folder containing a package.json file, looks for that “dependencies” object, and locally installs all of the packages necessary for running a given project.

This means, you could download Cody’s project right now (by cloning the repository or downloading the zipped files), navigate to the folder in your terminal, execute “npm install” followed by “npm start” and spin it up on your own machine.

As you grow as a developer and expose yourself to more professional workflows, it will become more and more ubiquitous that projects require some kind of dependency install and/or build process to get up and running. It will be rare where you’re working on a project with a static index.html file in the root project folder which you can just double-click on and open in browser.

So get used to the idea. I wish someone had taken the time to explain a package.json file to me this way when I first transitioned into more complex project workflows.

Experiment. Find some Github repos and try to spin up the authors’ projects on your own computer.

Next up: SSH keys and ES6.

Evan is an illustrator, developer, designer, and animator who tells stories in any which way he can. When he’s not branding businesses or building front-end apps; he’s illustrating children’s books, painting for tabletop games, animating commercials, or developing passion projects of his own.