Typescript: paths & baseUrl is not supported in typescript?

[azarus]

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"

[mhegazy]

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]

Also see https://github.com/Microsoft/TypeScript/issues/14651#event-1001825295

[mhegazy]

And https://github.com/Microsoft/TypeScript/issues/15479

[azarus]

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.

[mhegazy]

Whats the use case of this then?

if you are using a module loader with path configuration like SystemJs or require.

There seems to be no way of getting rid of relative path names

that is how ES6 modules are. there are no loaders for ES6, and there is no path mapping.

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.

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

[azarus]

Thanks thats a hacky way still but hopefully manageable. Much appreciated.

[mhegazy]

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

[azarus]

Just lol.

[azarus]

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.

[prograhammer]

So do I understand correctly that there is no functionality in TypeScript to help with avoid relative paths in module imports? For example, Webpack has an alias where you can set @ to alias to another folder resolved as absolute path. In other words, it will update an import like import '@/compX' to the proper absolute path import '/home/david/example/src/compX'.

This stackoverflow answer seems to suggest this is possible?

[vladimiry]

@prograhammer correct, at the moment TypeScript resolves the aliases during the compilation process, but doesn't change the aliases in the final/generated code. That's why for example I build everything using Webpack for now, it's simpler for me than adding some scripts just to handle the aliases rewriting issue.

[prograhammer]

Ah ok, just run it through Webpack (via ts-loader) and it will update the generated code correctly?

[vladimiry]

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.

[thatisuday]

@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/*"],

[alvis]

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.

[rdsedmundo]

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.