Getting Your JavaScript Environment Right
Most people spend more time fighting their build tools than actually writing code. I ran into this last year when a client's Next.js project would compile fine locally but fail in CI with a module resolution error that appeared nowhere in the documentation. The fix was adding "moduleResolution": "node" to tsconfig.json alongside the existing "bundler" setting. One line. Three hours of debugging saved. Here's what you actually need, stripped of the noise most tutorials add. Node.js Installation
Use the LTS version. Don't install from the Node website directly if you switch between projects frequently. Download nvm (Node Version Manager) instead. It takes about 10 minutes to set up and saves you from the headache of managing multiple project dependencies later. On macOS, brew install nvm. On Windows, grab the installer from the GitHub releases page. After installation, run nvm install --lts and nvm use --lts. Verify with node --version and npm --version. If either command fails, your PATH is misconfigured. Edit ~/.zshrc or ~/.bash_profile and add the nvm export block it prints during install. Restart your terminal. Project Initialization
Run npm init -y in your project folder. This creates package.json without prompting you through every field. Add your dependencies with npm install [package] and the --save flag by default in modern npm versions. For development-only tools like eslint or prettier, use --save-dev instead. I've seen too many developers skip the npm install step before running their code. Node won't find modules that aren't installed. It sounds obvious, but the "Cannot find module" error appears in literally every beginner tutorial comment section I've read. Package.json Essentials
Get the Full Details
Your package.json needs at minimum a name, version, main entry point, and scripts. Here's a typical starting structure: {
"name": "your-project",
"version": "1.0.0",
"main": "index.js",
"scripts": {
"start": "node index.js",
"dev": "nodemon index.js",
"test": "jest"
},
"dependencies": {},
"devDependencies": {}
} The scripts field is where most project-specific commands live. Add custom ones as your project grows. I keep a lint script and a build script in nearly every project I touch.
ESLint and Prettier Setup Run npx eslint --init to generate a config file. It will ask you a series of questions about your project type and style preferences. Pick the options that match your team's conventions. Wrong choices here cause friction later when code review flags formatting issues. For Prettier, install it separately and add a .prettierrc file at your project root. I typically configure it with single quotes, trailing commas, and an 80-character print width. These settings are conservative but widely accepted across codebases.
Git Integration Create a .gitignore file before you make your first commit. Include node_modules/, .env, and any build output directories. Without these excluded, your repository grows unnecessarily and you risk leaking environment variables into version control. The .env file alone can cause serious security incidents if pushed publicly. I once inherited a repository where the developer had committed their .env file with API keys. We spent two full days rotating credentials after discovering it. It's easy to forget this step in the excitement of starting a new project.
Environment Variables Use the dotenv package for local development. Install it with npm install dotenv and add require('dotenv').config() at the top of your entry file. Create a .env file with your variables in KEY=VALUE format. Don't add quotes around values unless they contain special characters. For production, set environment variables through your hosting provider's dashboard or CI/CD pipeline. Never embed secrets in your source code. This goes for both development and production environments.
Common Pitfalls One issue that catches experienced developers off guard: npm version mismatches between your local machine and the build server. I've lost half a day to this exact problem when a project worked locally but failed in deployment due to a different npm major version handling dependency resolution differently. Pin your Node and npm versions using an .nvmrc file to prevent this. Another issue is global package installation. Avoid it when possible. Global packages create inconsistent environments across machines and make project dependencies unclear. Use npx to run one-off commands or install packages locally within your project instead.
When This Approach Breaks This setup works well for most Node.js backend projects and simple frontend applications. However, it falls apart for large-scale React or Vue projects where tooling complexity explodes. In those cases, consider using a framework scaffolding tool like create-react-app, Vite, or Next.js instead of building from scratch. The abstractions they provide save significant time, even though they add their own constraints. Similarly, if your project requires TypeScript from the start, the manual ESLint and bundler configuration becomes considerably more involved. The typescript-eslint adapter adds another layer of complexity that's easier to avoid by starting with a TypeScript-aware template.
Final Notes The JavaScript ecosystem moves fast. What worked two years ago may not be the best approach today. The cheat sheet concept here is meant as a starting point, not a permanent reference. Revisit your tooling choices every six months or so. Dependency audits with npm audit and regular updates help keep security issues from accumulating silently. If you're starting fresh and want something faster, check out the JavaScript Setup Guide Cheat Sheet that the community maintains on GitHub. It covers additional scenarios like Docker containerization and CI/CD pipeline setup that this guide doesn't address.
