DEV Community

Restructure with ease thanks to Typescript path mappings

Stephen Cooper on November 08, 2019

The hardest part about restructuring a Typescript project is updating all the import paths. While many of our favourite editors can help us, there ...

Read full post

Satvik Sharma • Nov 12 '19 • Edited

At work we've just moved away from non relative imports to completely relative paths.

Few reasons for this:

Don't have to teach every tool we use how to resolve them
Don't have to teach everyone how we're special

This also leads to benefits like less configuration needed and that we can't break anyone's dev experience if their editor can't resolve an import, especially while we still have a mix of Flow/JS and are migrating to TS.

Luqman Hakim • Nov 11 '19

you shouldn't change the baseUrl, it'll make your life easier..
the path will be like this:
"~app/*": ["src/app/*"],

with this, you don't have to change your imports all at once..

Stephen Cooper • Nov 11 '19

Thanks for the heads up! I did not run into the issue of having to change all my imports at once with my current project but can see why this might cause issues.

Setup without modifying the value of the baseUrl.

"compilerOptions": {
    "baseUrl": "./",
    "paths": {
      "~app/*": ["src/app/*"],
      "~environments": ["src/environments/environment"],
    }
  }

Esirei • Nov 9 '19

Ah... I see you use ~ for your path prefixes. Personally I use @, but I've been thinking of changing it recently since I have a @types path that clashes with the @types libraries.
Thanks.

Richard Davenport • Nov 11 '19

I always prefix with the project prefix, or just @app.

EECOLOR • Nov 13 '19 • Edited

For this reason we use leading slash imports. /* => src/*

cname87 • Nov 12 '19

I had read the docs on these settings but didn't get the practical usage. Your article made that clear

Gal • Nov 10 '19

This makes me want to learn TypeScript! Thanks for the useful article. :)

Lars Rye Jeppesen • Nov 10 '19

You can do the same with babel

Stephen Cooper • Nov 10 '19

Go for it! :)

Tatsunix • Nov 9 '19

It's posts like this that made me subscribe. Thanks for the tip!

Lucas Diedrich • Nov 13 '19

Thanks a lot, always wanted to learn about how could I get rid of import ../.

Roland Csibrei • Nov 9 '19

Cool! Thanks!

Lonli-Lokli • Nov 9 '19

Why do you care about it? It's automatically done by vs code.
Also you may get issues if you will try to convert your code into the library.

Stephen Cooper • Nov 9 '19

While vs code can update your files, in my personal experience, it has not been 100% reliable in updating all my imports.

An additional benefit of the imports not changing with a refactor is that your pull requests will be much cleaner. In Github, for example, a file can then be reported as 'Moved with no file changes' which makes life a lot easier for your reviewer.

As for converting to library code I have actually seen that path mappings can be used positively. Say you have some shared code under your /app/common folder, you could setup a path mapping to it with the name @my-lib. This would enable you to refer to it like it was a real npm package. Then when you do extract the code into a separate package you just have to remove the path mapping and everything will just work with no updates to the rest of your code. Predicting the library name will be your biggest challenge here!

Would be interested to know what issues you are referring to in case I have missed something?