JavaScript Setup Guide

Getting JavaScript Running on Your Machine

The first thing most people do wrong is try to run JavaScript in the browser console and assume that's their entire development environment. It isn't. You need Node.js installed if you want to write anything beyond simple browser scripts. Go to nodejs.org, grab the current LTS build, and run the installer. That's it for the runtime. The actual setup splits into two paths depending on what you're building. If you're building a project with dependencies, bundlers, or build steps, initializing a package.json file is non-negotiable. Run npm init -y in your project root. It creates the config file with defaults. From there, you install whatever you need. For a basic project, that's usually just the bundler or framework. I've seen people skip this step and then spend three hours debugging why their imports aren't resolving across files. The other path is if you just want to prototype something quick. In that case, you don't need anything besides a text editor and a browser. Save your file as .js, open it in Chrome or Firefox, and use the DevTools console. That's the fastest way to get from zero to something running on screen. It's not production-ready architecture, but it gets code out the door.

Here's a detail most tutorials gloss over: Node.js versions matter more than people think. I had a project that worked fine on Node 18, broke completely when my teammate updated to Node 20 because of a subtle change in how ES module resolution works between the two. The workaround was adding "type": "module" to the package.json and renaming files to use .mjs extension for modules that needed it. It's a pain, but you'll hit it eventually. Another thing nobody warns you about is the global process.env behavior. When you're running Node scripts, environment variables are accessible, but they behave differently depending on how you launch the script. If you run node script.js directly, env vars from your shell are passed through. But if you use a package.json "scripts" entry with something like nodemon or a bundler wrapper, the behavior can change. I spent a day tracking down why a config value was undefined only to find that the build tool was stripping unknown environment variables before the code even ran. For the actual project structure, keep it simple at first. A typical layout looks like this:

src/ — your source code
dist/ — where built output goes
package.json — dependencies and scripts
node_modules/ — dependencies (don't commit this)
.gitignore — keep node_modules and dist out of version control The only part people mess up on here is the .gitignore. If you forget to exclude node_modules, your repo bloats instantly and every clone takes forever. Make sure you have a proper .gitignore from the start. There are generators online that give you sensible defaults for JavaScript projects. When it comes to package management, npm is the default, but you might want to consider using bun or pnpm instead. Bun is faster and handles TypeScript natively without extra tooling. Pnpm uses a content-addressable store that saves disk space significantly compared to npm's flat node_modules structure. I switched our team to pnpm and cut the local storage footprint by roughly 60 percent on a mid-sized project. It's not always necessary, but it scales better as dependency trees get deeper.

One common trap: don't install dev dependencies in your global npm namespace. Every time someone has run npm install -g something, it leaks into their global packages and causes version conflicts on other projects. Always install locally unless you actually need a CLI tool available system-wide, and even then verify it's not going to interfere with something else. If you're working with TypeScript alongside JavaScript, add the compiler and type definitions after your base setup. npm install -D typescript @types/node, then run npx tsc --init to generate a tsconfig.json. Most people skip the config step and wonder why their JSX or decorators don't work. The default tsconfig leaves a lot of flags commented out with brief descriptions, and reading through those actually helps you understand what each setting does to your compilation. For testing, set up whatever framework matches your project size. Jest is the default recommendation and works fine for unit tests. Vitest is faster and plays nicer with modern module resolution, though it's newer and has fewer third-party integrations. I usually start projects with Vitest because the dev mode is nearly instant, which matters more than you'd think when you're running tests constantly.

The one scenario where this setup completely falls apart is when you're targeting legacy environments that don't support modern JavaScript features. If you need to support IE11 or very old Node versions, you'll need a transpiler like Babel configured, and that adds real complexity. The tradeoff is genuine maintenance overhead. I've maintained a Babel config for an internal tool for two years, and honestly, every time the toolchain updates there's a chance something breaks. If you can avoid the constraint, do it.