React Tutorial 0/120 lessons ~6 min read Lesson 7“Modern frontend engineering”

React Project Setup

React Project Setup explains modern React and TypeScript project organization with Vite, package configuration, source and public assets, environment variables, feature boundaries, Git, quality tooling, CI/CD, and enterprise architecture.

Course progress0%

Focus

48 guided sections

Practice signal

Examples included

Career prep

Interview Q&A included

Learning Objectives

By the end of this lesson, you will be able to:

Understand what a React project setup actually contains.
Create a modern React + TypeScript project.
Understand the role of Node.js, npm, and the package manager.
Understand the role of Vite in a React project.
Understand the project directory structure.
Understand package.json and lockfiles.
Understand src, public, and the application entry point.
Understand main.tsx, App.tsx, and index.html.
Understand development and production scripts.
Configure environment variables safely.
Understand basic Git setup for a React project.
Establish a professional project structure suitable for scaling.
Understand common project-setup mistakes.
Troubleshoot common setup problems.
Explain React project setup from a senior-engineering perspective.

Introduction

In the previous lesson, we installed React.

Now we need to go one level deeper.

Installing React gives us the library.

Project setup gives us the environment in which the application will be developed, tested, built, and eventually deployed.

Think about a React application like this:

text

                    React Application
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
    Source Code         Tooling          Configuration
        │                  │                  │
        ▼                  ▼                  ▼
   Components           Vite             TypeScript
   Hooks                npm              ESLint
   Services             Build            Testing
   Pages                Dev Server       Environment
        │                  │                  │
        └──────────────────┼──────────────────┘
                           ▼
                       Production

A professional React developer should understand all three areas.

What Is React Project Setup?

A React project setup defines:

text

Project
│
├── Application source
├── Dependencies
├── Build configuration
├── Development server
├── TypeScript configuration
├── Environment configuration
├── Testing
├── Code quality
└── Deployment configuration

For a simple learning project, this may be relatively small.

For an enterprise application, it can become much more sophisticated.

Recommended Setup for This Course

For this course, we'll use:

text

React
+
TypeScript
+
Vite
+
npm
+
VS Code
+
Modern Browser

The basic architecture is:

text

Developer
    │
    ▼
VS Code
    │
    ▼
React + TypeScript
    │
    ▼
Vite
    │
    ▼
Browser

For learning React fundamentals, this gives us a relatively clean environment.

For a production application, you should evaluate whether a React framework is more appropriate.

Create the Project

Open your terminal.

Run:

bash

npm create vite@latest techlearningpro-react -- --template react-ts

This creates:

text

techlearningpro-react/

Now enter the directory:

bash

cd techlearningpro-react

Install dependencies:

bash

npm install

Start the development server:

bash

npm run dev

You should see a local URL in the terminal, commonly:

text

http://localhost:5173

The exact port can vary.

What Did We Just Create?

The generated project will contain files similar to:

text

techlearningpro-react/
│
├── public/
│
├── src/
│   ├── assets/
│   ├── App.tsx
│   ├── App.css
│   ├── index.css
│   └── main.tsx
│
├── .gitignore
├── index.html
├── package.json
├── package-lock.json
├── tsconfig.json
├── tsconfig.app.json
├── tsconfig.node.json
└── vite.config.ts

The exact generated structure can change between tool versions.

Don't memorize the filenames.

Understand their responsibilities.

The Big Picture

The most useful mental model is:

text

                    React Project
                         │
       ┌─────────────────┼──────────────────┐
       ▼                 ▼                  ▼
    Runtime            Source             Tooling
       │                 │                  │
       ▼                 ▼                  ▼
    Browser             src/              Vite
       │                 │                  │
       │            ┌────┼────┐             │
       │            ▼    ▼    ▼             │
       │          App  Components Hooks     │
       │                 │                  │
       └─────────────────┼──────────────────┘
                         ▼
                       Build
                         │
                         ▼
                    Production

package.json

One of the most important files is:

text

package.json

It describes the project.

A simplified example:

json

{
  "name": "techlearningpro-react",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "lint": "eslint .",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "...",
    "react-dom": "..."
  },
  "devDependencies": {
    "typescript": "...",
    "vite": "..."
  }
}

The exact versions depend on when the project is created.

Why package.json Matters

It tells the development environment:

text

What is this project?
        │
        ├── What packages does it need?
        │
        ├── What scripts can I run?
        │
        ├── What tools are required?
        │
        └── What version constraints exist?

For example:

bash

npm run dev

looks at:

json

"scripts": {
  "dev": "vite"
}

and executes the associated command.

Dependencies vs DevDependencies

You will commonly see:

json

"dependencies": {}

and:

json

"devDependencies": {}

Dependencies

Packages needed by the application/runtime model.

Examples:

text

react
react-dom

DevDependencies

Packages primarily used during development/building/testing.

Examples:

text

vite
typescript
eslint
testing tools

The exact classification can vary based on tooling and deployment strategy, but this distinction is important for project management.

package-lock.json

When you run:

bash

npm install

npm creates or updates:

text

package-lock.json

This records the resolved dependency tree.

Conceptually:

text

package.json
      │
      ▼
Version ranges
      │
      ▼
Dependency Resolution
      │
      ▼
package-lock.json
      │
      ▼
Exact dependency tree

This helps different environments install compatible versions.

For application repositories, the lockfile should normally be committed to source control.

node_modules

After installation:

text

node_modules/

appears.

It contains installed packages.

Conceptually:

text

node_modules/
│
├── react
├── react-dom
├── vite
├── typescript
├── eslint
└── dependencies...

It can become very large.

You generally do not commit it to Git.

Instead:

text

Git Repository
│
├── package.json
├── package-lock.json
└── src/

Then another developer can run:

bash

npm install

.gitignore

A React project should have a .gitignore.

Typical entries include:

text

node_modules/
dist/
.env
.env.local

The purpose is to prevent generated files and sensitive local configuration from being committed.

For example:

text

node_modules
      ↓
Generated dependency directory
      ↓
Do not commit

The src Directory

The most important application directory is generally:

text

src/

This is where your application source code lives.

Initially:

text

src/
│
├── App.tsx
├── main.tsx
├── App.css
├── index.css
└── assets/

As the application grows, we'll organize it more deliberately.

For example:

text

src/
│
├── components/
├── features/
├── pages/
├── hooks/
├── services/
├── types/
├── utils/
├── assets/
├── App.tsx
└── main.tsx

main.tsx

This is commonly the entry point of a Vite React application.

A simplified version:

tsx

import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import App from "./App";
createRoot(
  document.getElementById("root")!
).render(
  <StrictMode>
    <App />
  </StrictMode>
);

This file connects:

text

Browser DOM
     │
     ▼
React
     │
     ▼
App

index.html

At the root of the project you'll find:

text

index.html

A simplified version contains:

html

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport"
          content="width=device-width, initial-scale=1.0" />
    <title>TechLearningPro</title>
  </head>
  <body>
    <div id="root"></div>
    <script
      type="module"
      src="/src/main.tsx">
    </script>
  </body>
</html>

The important element is:

html

<div id="root"></div>

React uses this element as the mounting point.

Complete Startup Flow

Now connect everything.

text

Browser
   │
   ▼
index.html
   │
   ▼
<div id="root">
   │
   ▼
main.tsx
   │
   ▼
createRoot()
   │
   ▼
<App />
   │
   ▼
Component Tree
   │
   ▼
React Rendering
   │
   ▼
Browser UI

This is one of the most important diagrams to remember.

App.tsx

App.tsx commonly acts as the root component.

Example:

tsx

function App() {
  return (
    <main>
      <h1>
        Welcome to TechLearningPro
      </h1>
      <p>
        Learn React step by step.
      </p>
    </main>
  );
}
export default App;

Eventually, App should not become a giant component.

Instead:

text

App
│
├── Header
├── Navigation
├── Main
│   ├── Hero
│   ├── CourseList
│   └── LearningStats
└── Footer

public Directory

You may also have:

text

public/

This directory is useful for assets that need to be served as static files without being processed through the normal source module pipeline.

For example:

text

public/
├── favicon.ico
├── robots.txt
└── static-assets/

Use it intentionally.

Don't automatically place every image in public.

For many application assets, importing them from src is preferable because the build tool can process and reference them appropriately.

src/assets

Vite projects often include:

text

src/assets/

This can contain assets imported by application code:

tsx

import logo from "./assets/logo.svg";

Then:

tsx

<img src={logo} alt="TechLearningPro" />

This allows the build system to understand the asset as part of the application dependency graph.

vite.config.ts

This file configures Vite.

A simplified example might look like:

tsx

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
export default defineConfig({
  plugins: [react()]
});

The configuration can later include things such as:

text

Aliases
Proxy
Plugins
Build configuration
Server settings

For example, you may eventually want:

text

@/
  ↓
src/

instead of:

text

../../../../components

Why Aliases Matter

Imagine:

tsx

import Button from "../../../../components/Button";

This becomes difficult to read.

An alias can allow:

tsx

import Button from "@/components/Button";

Conceptually:

text

@/
 ↓
src/

Then:

text

@/components
@/features
@/services
@/hooks

become easier to manage.

However, aliases should be introduced consistently across TypeScript and build tooling.

TypeScript Configuration

A modern Vite React TypeScript project may contain several TypeScript configuration files.

For example:

text

tsconfig.json
tsconfig.app.json
tsconfig.node.json

These separate TypeScript concerns between:

text

Application
Node-based tooling
Project references/configuration

You don't need to memorize every setting initially.

Understand the purpose:

TypeScript configuration tells the compiler how your project's TypeScript code should be understood and checked.

Why TypeScript?

Consider:

tsx

function CourseCard({
  course
}) {
  return (
    <h2>{course.title}</h2>
  );
}

What exactly is course?

TypeScript allows:

tsx

interface Course {
  id: string;
  title: string;
  duration: number;
}
function CourseCard({
  course
}: {
  course: Course;
}) {
  return (
    <h2>{course.title}</h2>
  );
}

Now the component has an explicit contract.

This becomes extremely valuable in larger applications.

Scripts

Run:

bash

npm run

You can see the available scripts.

A typical Vite project includes scripts similar to:

text

dev
build
lint
preview

Development

bash

npm run dev

Production build

bash

npm run build

Linting

bash

npm run lint

Preview production build

bash

npm run preview

The exact scripts depend on the generated project and your configuration.

Development Lifecycle

When you execute:

bash

npm run dev

the flow is:

text

Terminal
   │
   ▼
npm
   │
   ▼
Vite
   │
   ▼
Development Server
   │
   ▼
Browser

When you edit:

text

App.tsx

the development tooling detects the change and updates the browser.

This is the development feedback loop:

text

Write Code
    │
    ▼
Save
    │
    ▼
Vite detects change
    │
    ▼
React refresh
    │
    ▼
Browser updates

Production Lifecycle

Production is different.

You run:

bash

npm run build

Conceptually:

text

Source
  │
  ▼
TypeScript / JSX
  │
  ▼
Build Tool
  │
  ├── Optimize
  ├── Transform
  ├── Bundle
  └── Generate assets
  │
  ▼
dist/

Then the resulting assets are deployed.

Environment Variables

Real applications often need environment-specific configuration.

For example:

text

Development API
Production API
Analytics configuration
Feature flags

With Vite, client-exposed environment variables commonly use the VITE_ prefix.

For example:

text

.env.development

could contain:

text

VITE_API_BASE_URL=https://dev-api.example.com

And production:

text

.env.production

could contain:

text

VITE_API_BASE_URL=https://api.example.com

Then:

tsx

const apiUrl = import.meta.env.VITE_API_BASE_URL;

Important Security Warning

This is extremely important.

Anything exposed to browser-side React code should be treated as public.

Do not put:

text

Database password
Private API secret
JWT signing key
Cloud secret
Payment secret

into:

text

VITE_SECRET_KEY

or any other client-side environment variable expecting it to remain secret.

The browser must receive the value.

Therefore:

text

Frontend environment variable
          ↓
       Browser
          ↓
     NOT a secret

Secrets belong on trusted server-side infrastructure.

Feature-Based Project Structure

As the application grows, avoid putting everything into:

text

src/components/

A large enterprise application might use:

text

src/
│
├── app/
│   ├── router/
│   ├── providers/
│   └── store/
│
├── features/
│   ├── authentication/
│   ├── courses/
│   ├── learning/
│   ├── payments/
│   └── profile/
│
├── components/
│   ├── Button/
│   ├── Modal/
│   └── DataTable/
│
├── services/
├── hooks/
├── types/
├── utils/
├── assets/
│
├── App.tsx
└── main.tsx

This is much closer to how a large application can be organized.

Feature vs Shared Component

This distinction is extremely important.

Suppose we have:

text

CourseCard

which is specific to the course domain.

It belongs naturally under:

text

features/courses/

But:

text

Button
Modal
Tooltip
Input

might belong to:

text

components/

because they are generic UI building blocks.

Think:

text

Feature
  ↓
Business/domain-specific
Shared component
  ↓
Generic/reusable

Recommended Enterprise Structure

A more mature structure could look like:

text

src/
│
├── app/
│   ├── App.tsx
│   ├── routes/
│   ├── providers/
│   └── config/
│
├── features/
│   ├── auth/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   ├── types/
│   │   └── pages/
│   │
│   ├── courses/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   ├── types/
│   │   └── pages/
│   │
│   └── learning/
│       ├── components/
│       ├── hooks/
│       ├── services/
│       └── pages/
│
├── components/
├── hooks/
├── services/
├── types/
├── utils/
└── assets/

This isn't a mandatory structure.

The important principle is:

Organize around business boundaries rather than blindly organizing around file types.

Application Boundaries

Imagine:

text

features/
├── courses/
├── payments/
└── authentication/

You don't want:

text

Payments
   ↓
random dependency
   ↓
Courses
   ↓
Authentication
   ↓
Payments

creating circular business dependencies.

Instead:

text

Authentication
       │
       ▼
Application
       │
 ┌─────┼──────┐
 ▼     ▼      ▼
Courses Payments Learning

Clear boundaries make large systems easier to evolve.

React Providers

As applications become more complex, the root may contain providers:

tsx

function App() {
  return (
    <AuthProvider>
      <ThemeProvider>
        <RouterProvider />
      </ThemeProvider>
    </AuthProvider>
  );
}

Conceptually:

text

App
│
└── AuthProvider
    │
    └── ThemeProvider
        │
        └── Router
            │
            └── Pages

We'll study these concepts later.

Don't add providers simply because a library provides one.

Every global provider introduces another architectural dependency.

Git Setup

Initialize Git if necessary:

bash

git init

Then:

bash

git add .
git commit -m "Initial React project setup"

A good repository should contain:

text

src/
package.json
package-lock.json
README.md
.gitignore
configuration files

It should generally not contain:

text

node_modules/
dist/
local secrets

README

Even a learning project should have:

text

README.md

For example:

markdown

# TechLearningPro React

React + TypeScript learning project.

## Requirements

- Node.js
- npm

## Installation

npm install

## Development

npm run dev

## Production Build

npm run build

For enterprise applications, the README should become much more comprehensive.

Enterprise README

A professional project README might contain:

text

Project Overview
Architecture
Prerequisites
Installation
Environment Setup
Development
Testing
Build
Deployment
Troubleshooting
Contribution Guidelines
Branching Strategy
Security
Contacts

This reduces onboarding time.

Linting

Linting catches common code-quality problems.

For example:

text

Unused variables
Invalid patterns
Potential bugs
Inconsistent code
React-specific issues

A typical project may use ESLint.

Run:

bash

npm run lint

The exact rules should be agreed upon by the team.

Formatting

Teams often use an automated formatter such as Prettier.

Instead of developers debating:

text

spaces vs tabs
single vs double quotes
line length
semicolon rules

the formatter makes the decision automatically.

This is important:

Code formatting should be automated, not debated during code review.

Testing Setup

A production React project should eventually have multiple levels of testing.

text

Testing
│
├── Unit
├── Component
├── Integration
└── End-to-End

For example:

text

Component
   │
   ▼
User Interaction
   │
   ▼
Expected UI

We'll cover testing in a dedicated section later.

Common Project Setup Mistakes

Mistake 1: One giant App.tsx

Avoid:

text

App.tsx
└── 3,000 lines

Prefer meaningful boundaries.

Mistake 2: Everything in components/

Avoid:

text

components/
├── Course
├── Payment
├── Auth
├── Dashboard
├── Button
├── Modal
└── EverythingElse

Separate domain-specific features from generic components.

Mistake 3: Global state for everything

Not every value belongs in global state.

Ask:

Who actually needs this data?

Mistake 4: Secrets in .env

.env does not automatically make browser-exposed secrets secure.

Mistake 5: Committing node_modules

Don't.

Mistake 6: No lockfile

For application repositories, the dependency lockfile is normally part of source control.

Mistake 7: Too many dependencies

Every dependency adds:

text

Maintenance
Security
Upgrade
Bundle
Compatibility

cost.

Mistake 8: Overengineering on day one

Don't create:

text

50 folders
20 abstractions
15 providers

before the application needs them.

Practical Setup Exercise

Create:

text

techlearningpro-react/

Then organize:

text

src/
│
├── components/
│   └── Header.tsx
│
├── features/
│   └── courses/
│       └── CourseCard.tsx
│
├── pages/
│   └── HomePage.tsx
│
├── App.tsx
└── main.tsx

Header.tsx

tsx

export function Header() {
  return (
    <header>
      <h1>TechLearningPro</h1>
    </header>
  );
}

CourseCard.tsx

tsx

interface CourseCardProps {
  title: string;
  level: string;
}
export function CourseCard({
  title,
  level
}: CourseCardProps) {
  return (
    <article>
      <h2>{title}</h2>
      <p>{level}</p>
    </article>
  );
}

HomePage.tsx

tsx

import { CourseCard } from "../features/courses/CourseCard";
export function HomePage() {
  return (
    <main>
      <h2>Featured Courses</h2>
      <CourseCard
        title="React Mastery"
        level="Advanced"
      />
      <CourseCard
        title="Spring Boot"
        level="Advanced"
      />
    </main>
  );
}

Update App.tsx

tsx

import { Header } from "./components/Header";
import { HomePage } from "./pages/HomePage";
function App() {
  return (
    <>
      <Header />
      <HomePage />
    </>
  );
}
export default App;

Now the architecture is:

text

App
│
├── Header
│
└── HomePage
    │
    ├── CourseCard
    └── CourseCard

What You Should Learn From This Exercise

Don't focus only on creating folders.

Understand the dependency direction:

text

App
 │
 ▼
Page
 │
 ▼
Feature
 │
 ▼
Component

For example:

text

App
 ↓
HomePage
 ↓
courses
 ↓
CourseCard

The goal is to make dependencies understandable.

Interview questions & answers

Interview preparation

15 questions grouped by difficulty — expand any card for a model answer and follow-up probe.

Beginner

1What is a React project?
Beginner
Model answer
A React project is an application codebase that uses React along with the required development and build tooling.
It normally contains source code, dependency configuration, build configuration, and scripts for development, testing, and production builds.
2What is package.json?
Beginner
Model answer
package.json is the main project metadata and dependency configuration file in a Node-based JavaScript project. It contains information such as project scripts, dependencies, and development dependencies.
3What is node_modules?
Beginner
Model answer
It's the directory where npm installs the project's dependencies.
We normally don't commit it to Git because it can be recreated from the package configuration and lockfile.
4What is main.tsx?
Beginner
Model answer
In a typical Vite React TypeScript application, main.tsx is the entry point that creates the React root and renders the application's root component into the DOM.

Intermediate

5What is the purpose of index.html?
Intermediate
Model answer
It provides the initial HTML document loaded by the browser. It contains the DOM element where the React application is mounted, typically something like <div id="root"></div>.
6Why do we need Vite?
Intermediate
Model answer
Vite provides development and build tooling.
It gives us a development server, fast development feedback, and production build capabilities.
React itself doesn't provide all of those application development tools.
7What is the difference between src and public?
Intermediate
Model answer
src generally contains application source code and assets that participate in the module/build system. public is intended for static assets that need to be served directly. The exact usage should be based on the build tool's conventions.
8Why should we commit package-lock.json?
Intermediate
Model answer
It records the resolved dependency tree and helps make installations more reproducible across developer machines and CI environments.

Advanced

9How would you structure a large React project?
Advanced
Model answer
I'd generally organize around business or feature boundaries, with shared components and infrastructure separated from domain-specific code.
For example, authentication, courses, payments, and learning could each have their own feature boundaries.
I'd avoid blindly organizing everything by technical file type.
10How do you prevent a React project from becoming difficult to maintain?
Advanced
Model answer
I'd establish clear component and feature boundaries, control dependency direction, keep state close to where it is needed, avoid unnecessary global state, standardize TypeScript and linting, automate testing and CI, and regularly remove unnecessary dependencies and abstractions.
11What would you put in a React project .env file?
Advanced
Model answer
I'd put configuration that is appropriate for the client environment, such as an API base URL or public feature configuration.
I would never treat a browser-exposed environment variable as a secret.
12How would you design a React project for multiple teams?
Advanced
Model answer
I'd organize the code around business domains, define ownership boundaries, establish a shared design system where appropriate, enforce dependency rules, standardize tooling and CI, and minimize cross-domain coupling.
Shared libraries would need clear ownership because excessive sharing can become an organizational bottleneck.
13What is the difference between project structure and architecture?
Advanced
Model answer
Project structure is how files and directories are organized.
Architecture is broader—it defines responsibilities, dependencies, boundaries, data flow, runtime behavior, and system-level decisions.
A clean folder structure doesn't automatically mean the application has good architecture.
14Would you recommend the same React project structure for every application?
Advanced
Model answer
No.
A small application should remain simple.
A large enterprise platform needs stronger boundaries.
I'd start with the simplest structure that supports the current requirements and evolve it as complexity grows.
15How would you prepare a React application for CI/CD?
Advanced
Model answer
I'd make the build reproducible, commit the lockfile, use a supported Node version, run dependency installation consistently, execute linting and tests, run the production build, perform security checks, generate the deployment artifact, and promote that artifact through environments.

Production-Ready Mental Model

A professional React project isn't just:

text

React

It is:

text

                  React Application
                         │
       ┌─────────────────┼─────────────────┐
       ▼                 ▼                 ▼
     Source            Tooling         Configuration
       │                 │                 │
       ▼                 ▼                 ▼
 Components            Vite          TypeScript
 Features              npm           ESLint
 Pages                 Build         Environment
 Services              Test          CI/CD
       │                 │                 │
       └─────────────────┼─────────────────┘
                         ▼
                    Build Artifact
                         │
                         ▼
                      Deploy
                         │
                         ▼
                       Users

This is the mindset you should carry into enterprise React development.

Final Architecture

Remember this:

text

                 React Project
                      │
          ┌───────────┼───────────┐
          ▼           ▼           ▼
        Source      Tooling    Configuration
          │           │           │
          ▼           ▼           ▼
       Features      Vite      TypeScript
       Components    npm       Environment
       Pages         Build     ESLint
       Services      Test      CI/CD
          │           │           │
          └───────────┼───────────┘
                      ▼
                  Application
                      │
                      ▼
                    Build
                      │
                      ▼
                  Deployment
                      │
                      ▼
                    Browser

The key principle is:

A React project should be designed not only to run today, but to remain understandable as the application, team, and business requirements grow.

Next Lesson

React Project Structure

In the next lesson, we'll go deeper into the project we just created and understand every important folder and file, including:

text

src/
├── components/
├── features/
├── pages/
├── hooks/
├── services/
├── types/
├── utils/
└── assets/

We'll also establish a production-grade React folder architecture that we'll reuse throughout the rest of this course.

Key Takeaways

React project setup is broader than installing React.
package.json defines project dependencies and scripts.
package-lock.json helps provide reproducible installations.
node_modules contains installed dependencies and should generally not be committed.
index.html provides the initial browser document.
main.tsx commonly bootstraps the React application.
createRoot() connects React to the DOM.
App.tsx commonly represents the root component.
src contains application source code.
public contains assets intended for direct serving.
Vite provides development and build tooling.
TypeScript provides stronger contracts for application code.
Environment variables need careful security treatment.
Client-side environment variables are not secrets.
Feature-based organization can scale better than one giant shared components directory.
Shared components should remain genuinely generic.
Business-specific components should usually remain close to their feature.
Project structure should evolve with application complexity.
Linting, formatting, testing, and CI are part of professional project setup.
Good project setup creates clear boundaries so the application can grow without becoming chaotic.

Ready to mark this lesson complete?Track your journey across the entire course.

React Project Setup

Learning Objectives

Introduction

What Is React Project Setup?

Recommended Setup for This Course

Create the Project

What Did We Just Create?

The Big Picture

package.json

Why package.json Matters

Dependencies vs DevDependencies

Dependencies

DevDependencies

package-lock.json

node_modules

.gitignore

The src Directory

main.tsx

index.html

Complete Startup Flow

App.tsx

public Directory

src/assets

vite.config.ts

Why Aliases Matter

TypeScript Configuration

Why TypeScript?

Scripts

Development

Production build

Linting

Preview production build

Development Lifecycle

Production Lifecycle

Environment Variables

Important Security Warning

Feature-Based Project Structure

Feature vs Shared Component

Recommended Enterprise Structure

Application Boundaries

React Providers

Git Setup

README

Enterprise README

Linting

Formatting

Testing Setup

Common Project Setup Mistakes

Mistake 1: One giant App.tsx

Mistake 2: Everything in components/

Mistake 3: Global state for everything

Mistake 4: Secrets in .env

Mistake 5: Committing node_modules

Mistake 6: No lockfile

Mistake 7: Too many dependencies

Mistake 8: Overengineering on day one

Practical Setup Exercise

Header.tsx

CourseCard.tsx

HomePage.tsx

Update App.tsx

What You Should Learn From This Exercise

Interview questions & answers

Interview preparation

Beginner

Intermediate

Advanced

Production-Ready Mental Model

Final Architecture

Next Lesson

**React Project Structure**

React Project Structure