You’re refactoring. A large You create the new files, update the “Can I safely delete the original file now?”<\/em><\/p><\/blockquote>\n\n\n\n Maybe some file somewhere still imports directly from the old path:<\/p>\n\n\n\n Instead of the new barrel:<\/p>\n\n\n\n If you just delete the file and find out later, you’ll get a runtime crash \u2014 or worse, a broken build in CI.<\/p>\n\n\n\n Before touching anything, run a quick search across your entire No output = no direct imports found.<\/strong> You’re already in good shape.<\/p>\n\n\n\n Here’s what each part does:<\/p>\n\n\n\n Think of it as a dry run<\/strong> of your entire TypeScript compilation. It reads every file, resolves every import, checks every type \u2014 and reports errors without touching your If you had missed a stale import, you’d see something like:<\/p>\n\n\n\n Empty output = zero errors = your codebase is fully consistent.<\/strong> ?<\/p>\n\n\n\n It’s not just for file deletions. Reach for it whenever you:<\/p>\n\n\n\n It’s faster than Whenever you restructure your codebase, make it a habit:<\/p>\n\n\n\n Two commands. Thirty seconds. Zero surprises.<\/p>\n\n\n\n Tags: The situation You’re refactoring. A large models.ts file has grown too big \u2014 it mixes enums, interfaces, and types all in one place. Your team agrees: it’s time to split it into dedicated files (*.enums.ts, *.types.ts, *.interfaces.ts). You create the new files, update the index.ts barrel, and everything looks fine. But then comes the question […]<\/p>\n","protected":false},"author":1,"featured_media":1965,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[37],"tags":[40,1169,776,955,736,1167,161,217,1170,87,1168],"_links":{"self":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4437"}],"collection":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=4437"}],"version-history":[{"count":1,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4437\/revisions"}],"predecessor-version":[{"id":4438,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/4437\/revisions\/4438"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media\/1965"}],"wp:attachment":[{"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=4437"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=4437"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nguenkam.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=4437"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}models.ts<\/code> file has grown too big \u2014 it mixes enums, interfaces, and types all in one place. Your team agrees: it’s time to split it into dedicated files (*.enums.ts<\/code>, *.types.ts<\/code>, *.interfaces.ts<\/code>).<\/p>\n\n\n\nindex.ts<\/code> barrel, and everything looks<\/em> fine. But then comes the question that every developer knows:<\/p>\n\n\n\n\/\/ somewhere deep in your codebase...\nimport { IUploadState } from '..\/models\/upload.models';<\/code><\/pre>\n\n\n\nimport { IUploadState } from '..\/models';<\/code><\/pre>\n\n\n\n
\n\n\n\nStep 1 \u2014 Hunt down direct imports with
grep -r<\/code><\/h4>\n\n\n\nsrc\/<\/code> folder:<\/p>\n\n\n\ngrep -r \"upload.models\" src\/<\/code><\/pre>\n\n\n\ngrep -r<\/code> recursively searches all files in a directory for a given string. It’s fast, it’s reliable, and it immediately tells you if any file still references the old module path.<\/p>\n\n\n\n
\n\n\n\nStep 2 \u2014 Verify type consistency with
npx tsc --noEmit<\/code><\/h4>\n\n\n\ngrep<\/code> checks file references, but it doesn’t understand TypeScript. To make sure your entire type graph is still coherent after the refactor, run:<\/p>\n\n\n\nnpx tsc --noEmit<\/code><\/pre>\n\n\n\nPart<\/th> Role<\/th><\/tr><\/thead> npx<\/code><\/td>Runs a binary \u2014 from node_modules<\/code> if installed, or downloads it temporarily from the npm registry if not<\/em><\/td><\/tr>tsc<\/code><\/td>The TypeScript compiler<\/td><\/tr> --noEmit<\/code><\/td>Compiles everything in memory only<\/strong> \u2014 no files are generated or modified<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n dist\/<\/code> folder.<\/p>\n\n\n\nerror TS2307: Cannot find module '..\/models\/upload.models'\nor its corresponding type declarations.<\/code><\/pre>\n\n\n\n
\n\n\n\nWhen should you use
npx tsc --noEmit<\/code>?<\/h4>\n\n\n\nng build<\/code>, lighter than running tests, and gives you immediate, precise feedback on your type safety.<\/p>\n\n\n\n
\n\n\n\nTL;DR<\/h4>\n\n\n\n
# 1. Check for stale path references\ngrep -r \"old-file-name\" src\/\n\n# 2. Verify full type consistency\nnpx tsc --noEmit<\/code><\/pre>\n\n\n\n
\n\n\n\n#TypeScript<\/code> #Angular<\/code> #Refactoring<\/code> #DeveloperTools<\/code> #WebDev<\/code> #CleanCode<\/code> #Frontend<\/code> #tsc<\/code> #CLI<\/code><\/em><\/p>\n","protected":false},"excerpt":{"rendered":"