Setting Up React Properly
You want a clean React project that doesn't fall apart six months from now. The official Create React App is dead, which catches people off guard. Vite replaced it as the default recommendation, and for good reason. Let me walk you through the practical side of this. Start by picking a package manager and committing to it. npm, pnpm, or yarn — and I mean actually committing. Mixing them in the same project is how you end up with duplicate dependency trees that make no sense. I lost an entire afternoon to this once, debugging why a module was resolving differently in dev than in production. The fix was deleting the node_modules folder and running a fresh install with pnpm exclusively. Took ten minutes instead of four hours. Here's the command if you're going with Vite, which is what I recommend for anything beyond a simple demo:
npm create vite@latest my-app -- --template react-ts The --template react-ts flag gives you TypeScript out of the box. Don't skip it. A React project without TypeScript in 2024 is asking for runtime errors that your linter won't catch. I know people who refuse TypeScript because they find the syntax verbose. That's fine for hobby projects. When you're managing a codebase with multiple contributors, the type checking saves you from entire categories of bugs before they ship. After the project scaffold finishes, run npm install and then npm run dev. That should start the dev server on localhost:5173. If it doesn't, check your Node version. Vite requires Node 18 or higher. I ran into this a while back on a machine still on Node 16, and the error messages were unhelpful. Switched to nvm and set the project to use the latest LTS. Done.
Now let's talk about ESLint and Prettier. Most starter templates give you basic ESLint rules, but the default config is usually too lenient. You want the eslint-config-react-app plugin and the @vitejs/plugin-react for JSX support in linting. Add a .prettierrc file at the root level with these settings: {
"semi": true,
"trailingComma": "es5",
"tabWidth": 2,
"printWidth": 80,
"singleQuote": true
} That keeps formatting consistent without turning your code into unreadable spaghetti. I've worked on teams where nobody agreed on Prettier settings and every merge had formatting conflicts. Standardize early.
Get the Full Details
One thing most guides skip: environment variables. React builds treat process.env.REACT_APP_* variables as compile-time constants. If you need dynamic values at runtime, this approach breaks. Use vite-plugin-environment or configure your environment handling in vite.config.ts. I had a case where a client secret was hardcoded into the build output because I forgot about this distinction. Production incident. Fixed it by moving all secrets to actual runtime environment injection through the hosting platform. For state management, don't reach for Redux immediately. The ecosystem has moved toward lighter solutions. Zustand or Jotai handle most applications without the boilerplate Redux requires. Redux Toolkit exists to reduce the pain, and it works well, but you're still carrying more complexity than necessary for simple global state. Use context for prop drilling that goes two levels deep. Use Zustand for everything else. I set up a project with full Redux last year and spent three days writing slices for data that a simple Zustand store could have handled in twenty lines. Routing with React Router v6 is significantly different from v5. The data API (loaders and actions) replaces the old route props pattern. It's more flexible but takes a day to get comfortable with. A common mistake is treating it like the old version — trying to access route data through props instead of the new hooks like useLoaderData and useNavigation. The documentation covers this, but the examples don't emphasize the migration clearly enough.
Testing setup is another area where people rush. React Testing Library is the standard. Don't use Enzyme. It's deprecated and the community moved on. Pair RTL with Vitest instead of Jest — Vite's ecosystem already includes Vitest, and it's significantly faster. Hot reload for tests is a real thing with Vitest, and I can't stress enough how much time that saves during development. Setting up a test file looks like this: import { render, screen } from '@testing-library/react'
import { describe, it, expect } from 'vitest'
import App from './App'describe('App', () => {
it('renders the header', () => {
render(<App />)
expect(screen.getByRole('heading')).toBeInTheDocument()
})
})
There are tradeoffs to everything. Vite's build speed is great, but if you need IE11 support, you're out of luck. It doesn't support older browsers. For enterprise projects stuck on legacy browsers, you might still need to use Create React App or configure a fallback with SWC. The React team itself recommends Vite, so this is increasingly uncommon, but it's real. Another limitation: SSR with Vite requires additional tooling. Next.js handles SSR out of the box. If server-side rendering is a requirement from the start, Next.js may save you setup time even though it's more opinionated. Pure Vite is better for client-side SPAs. There's no universal answer here, and pretending there is would be dishonest. For production builds, always run npm run build and inspect the output before deploying. Check the size of your bundles. If something is unexpectedly large, use the Vite build analysis plugin to identify what's taking up space. Lazy loading with React's lazy() and Suspense can dramatically reduce initial bundle size for larger applications. I reduced a startup bundle from 2.3MB to 840KB by splitting routes into separate chunks.
That's the practical reality of setting up a React project that you can actually maintain. No magic. Just making the right choices upfront so you're not rewriting your infrastructure mid-project.
