TypeScript project structure, strict tsconfig, module resolution, path aliases, shared types, and monorepo patterns
90
84%
Does it follow best practices?
Impact
100%
1.09xAverage score across 5 eval scenarios
Passed
No known issues
A small team is building an online bookstore with a React frontend (using Vite) and an Express backend, both in TypeScript. They currently have the frontend and backend in the same repository but types are duplicated — the Book interface is defined separately in both src/types.ts (frontend) and server/types.ts (backend), and they've already had bugs where the two definitions drifted apart.
The team wants to restructure the project so that shared types are defined once and used by both sides. They also need proper tsconfig files for both frontend and backend, with the frontend using Vite's bundler resolution and the backend using Node.js module resolution.
Produce a project structure with:
package.json — with scripts for dev (concurrent client + server), build, typecheck (both configs), and starttsconfig.json — base config for the React frontend (bundler resolution, react-jsx)tsconfig.server.json — server config (NodeNext resolution, outDir for dist)vite.config.ts — Vite config with path alias for shared types.gitignore — proper ignoresshared/types.ts — Shared type definitions: Book, Author, CartItem, API request/response shapes, BookCategory union typesrc/App.tsx — Simple React component that imports from shared typessrc/api.ts — Frontend API client that uses shared types for request/responseserver/index.ts — Express server entry pointserver/routes/books.ts — Book CRUD routes that import from shared typesThe implementation does not need to be fully functional — focus on the project structure, tsconfig setup, shared types organization, and correct imports between shared/client/server.
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
skills
typescript-project-structure
verifiers