{
  "$type": "site.standard.document",
  "canonicalUrl": "https://johnnyreilly.com/posts/typescript-webpack-alias-goodbye-relative-paths",
  "description": "Use TypeScript with webpack alias to avoid long relative paths in imports. Try `path mapping` or `resolve.alias`. Use `tsconfig-paths-webpack-plugin`.",
  "path": "/posts/typescript-webpack-alias-goodbye-relative-paths",
  "publishedAt": "2018-08-21T00:00:00.000Z",
  "site": "at://did:plc:yy3apqjlms24kso7ahn7lbmb/site.standard.publication/3mova7c4nho2b",
  "tags": [
    "webpack",
    "typescript"
  ],
  "textContent": "This post shows how you can use TypeScript with webpack alias to move away from using relative paths in your import statements.\n\n\n\nLong relative paths\n\nI write a lot of TypeScript. Because I like modularity, I split up my codebases into discreet modules and import from them as necessary.\n\nTake a look at this import:\n\nNow take a look at this import:\n\nWhich do you prefer? If the answer was \"the first\" then read no further. You have all you need, go forth and be happy. If the answer was \"the second\" then stick around; I can help!\n\nTypeScript\n\nThere's been a solution for this in TypeScript-land for some time. You can read the detail in the \"path mapping\" docs here.\n\nLet's take a slightly simpler example; we have a folder structure that looks like this:\n\nWe would like page.tsx to import 'shared/utils' instead of '../shared/utils'. We can, if we augment our tsconfig.json with the following properties:\n\nThen we can use option 2. We can happily write:\n\nMy code compiles, yay.... Ship it!\n\nLet's not get over-excited. Actually, we're only part-way there; you can compile this code with the TypeScript compiler.... But is that enough?\n\nI bundle my TypeScript with ts-loader and webpack. If I try and use my new exciting import statement above with my build system then disappointment is in my future. webpack will be all like \"import whuuuuuuuut?\"\n\nYou see, webpack doesn't know what we told the TypeScript compiler in the tsconfig.json. Why would it? It was our little secret.\n\nwebpack resolve.alias to the rescue!\n\nThis same functionality has existed in webpack for a long time; actually much longer than it has existed in TypeScript. It's the resolve.alias functionality.\n\nSo, looking at that I should be able to augment my webpack.config.js like so:\n\nAnd now both webpack and TypeScript are up to speed with how to resolve modules.\n\nDRY with the tsconfig-paths-webpack-plugin\n\nWhen I look at the tsconfig.json and the webpack.config.js something occurs to me: I don't like to repeat myself. As well as that, I don't like to repeat myself. It's so... Repetitive.\n\nThe declarations you make in the tsconfig.json are re-stated in the webpack.config.js. Who wants to maintain two sets of code where one would do? Not me.\n\nFortunately, you don't have to. There's the tsconfig-paths-webpack-plugin for webpack which will do the job for you. You can replace your verbose resolve.alias with this:\n\nThis does the hard graft of reading your tsconfig.json and translating path mappings into webpack aliases. From this point forward, you need only edit the tsconfig.json and everything else will just work.\n\nThanks to Jonas Kello, author of the plugin; it's tremendous! Thanks also to Sean Larkin and Stanislav Panferov (of awesome-typescript-loader) who together worked on the original plugin that I understand the tsconfig-paths-webpack-plugin is based on. Great work!",
  "title": "Using TypeScript and webpack alias: goodbye relative paths"
}