TypeScript: paths & baseUrl is not supported in typescript?

Soo according to the documentation here: https://www.typescriptlang.org/docs/handbook/module-resolution.html

And this proposal here: https://github.com/Microsoft/TypeScript/issues/5039

I’ve tried to set up a simple typescript project using the paths and baseUrl path mapping to create shortcuts to folders.

Everything seemed fine in vscode but when i executed tsc from the commandline i found out its not working properly.

TypeScript Version: Version 2.3.3

Code tsconfig.json

{
  "compilerOptions": {
    "outDir": "./build/assets/js/",
    "sourceMap": true,
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es5",
    "allowJs": true,
    "baseUrl": "",
    "paths": {
        "@Core/*": [
            "source/Core/*"
        ]
    }
  }
}

Currently the following code is not resolved in tsc, and only resolved in vs code.

import { Test } from "@Core/Test"

This outputs an error that @Core/Test module is not found

Expected behavior: It should resolve to:

import { Test } from "../../Test"

Actual behavior: It stays the same in the output file, and is not resolved.

import { Test } from "@Core/Test"

About this issue

Original URL
State: closed
Created 7 years ago
Comments: 16 (5 by maintainers)

Most upvoted comments

This is a horrible thing to document on the documentation my expectations were that tsc will transform the module identifiers to proper path names. Whats the use case of this then? There seems to be no way of getting rid of relative path names. Is it really hard to get at least a basic plugin support feature so i can implemenr my own without hacking anything there. I am following the typescript development since the first versions… and this is the ONLY thing that got me off doing anything in typescript. And its been years now… babel has plugin support and currently i really would like to use typings in a project to avoid common errors but this is just quite frustrating.

+32

azarus on May 27, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

+21

mhegazy on Jun 14, 2017

you can use TS to emit to --target ESNext, then pass that to babel, and use the extension to rewrite your modules.

This simply doesn’t make sense.

I’m being suggested to include Babel for doing something that TypeScript could do, after all, doesn’t TypeScript replace its functionality entirely? Why do I need to have two compilers for resolving a single problem? That’s just lol as @azarus said.

If TypeScript doesn’t support this, then the entire compiler itself could be just a Babel plugin.

rdsedmundo on May 18, 2018

Just lol.

azarus on Jun 15, 2017

Path mapping does not rename your modules. it just tells the compiler where to find them. module names are considered resource identifiers and are not changed by the compiler.

see https://github.com/Microsoft/TypeScript/issues/5039#issuecomment-232470330

mhegazy on May 25, 2017

As far addressing the issue I’ve ended up with my own post build script. https://gist.github.com/azarus/f369ee2ab0283ba0793b0ccf0e9ec590 Browserify & Gulp samples included.

It acutally uses the tsconfig.json paths and baseUrl setup. I am gonna make a npm package from this during the weekend, i just haven’t had time to properly test the script.

Hopefully it helps others who run into this issue.

azarus on Jun 15, 2017

If you use ts-node, the tsconfig-paths package may help.

The transformation can also be done via babel with babel-plugin-module-resolver or webpack with tsconfig-paths-webpack-plugin.

alvis on Jan 30, 2018

@vladima @prograhammer Use https://github.com/mazhlekov/tsc-resolve but it only resolve index.ts paths like "@servers" : ["./networking/http/servers"], and not wildcard paths like "@servers/*" : ["./networking/http/servers/*"],

thatisuday on Jan 11, 2018

I prefer awesome-typescript-loader, but ts-loader is supposed to work as well I guess. Aliases rewriting in the final code is actually Webpack’s feature, like post processing step, so it should not really depend on the loader used.

vladimiry on Nov 25, 2017