How would you use tsconfig.json to enable shorter path aliases?

WHAT THIS TESTS: The interviewer wants to know if you can manipulate TypeScript module resolution through compiler configuration instead of accepting messy relative paths. They care whether you understand the relationship between baseUrl and paths inside compilerOptions, and whether you recognize that TypeScript path mapping is a compile-time convenience that does not automatically propagate to runtime or to your bundler without extra setup.

A GOOD ANSWER COVERS: First, set baseUrl inside compilerOptions, usually to the project root or the directory containing tsconfig.json, so non-relative module resolution has a starting anchor. Second, add a paths mapping under compilerOptions.paths, such as an entry where the key is @/* and the value is an array like src/*, which tells the compiler to resolve imports starting with @/ by looking under the src directory relative to baseUrl. Third, explicitly state that this only affects the TypeScript compiler and language service; the emitted JavaScript still contains the original import string, so your build tool whether that is Vite, webpack, Rollup, or esbuild must be configured with its own alias rules that mirror the tsconfig setup. Fourth, mention that omitting baseUrl causes paths mappings to fail because the compiler lacks an anchor directory.

COMMON WRONG ANSWERS: A major red flag is suggesting that you move files around to shorten imports, which misses the point of configuration-driven developer experience. Another is claiming that tsconfig paths rewrite import strings in emitted JavaScript, which it does not; TypeScript only uses paths for type checking and declaration emit. Candidates also sometimes forget baseUrl entirely and wonder why the alias fails, or they confuse paths with rootDirs, which is meant for merging multiple source directories into one virtual layout rather than creating import aliases.

LIKELY FOLLOW-UPS: The interviewer might ask how you keep tsconfig aliases in sync with a Vite or webpack config, or how you handle a monorepo where packages reference each other across directory boundaries. They might also probe whether path mapping affects declaration emit or if you need to publish path aliases in a library, which usually requires bundling or substituting the aliases before publication because consumers will not share your tsconfig.

ONE CONCRETE EXAMPLE: Imagine a project where tsconfig.json sits at the root and all source code lives in src. You would set compilerOptions.baseUrl to a single dot and compilerOptions.paths to an object mapping @/* to an array containing src/*. After restarting the language service, an import like import { MyUtil } from @/utils/MyUtil resolves correctly in the editor and during type checking. However, if you run the raw emitted JavaScript in Node.js without a bundler, the import string remains unchanged and fails at runtime because Node.js does not understand that alias. Therefore, you would also add a corresponding resolve.alias entry in your bundler configuration.