Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

paths & baseUrl is not supported in typescript? #16088

Closed
azarus opened this issue May 25, 2017 · 16 comments
Closed

paths & baseUrl is not supported in typescript? #16088

azarus opened this issue May 25, 2017 · 16 comments
Labels
Duplicate An existing issue was already created

Comments

@azarus
Copy link

azarus commented May 25, 2017

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

And this proposal here:
#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
Copy link
Contributor

mhegazy commented May 25, 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 #5039 (comment)

@mhegazy mhegazy added the Duplicate An existing issue was already created label May 25, 2017
@mhegazy
Copy link
Contributor

mhegazy commented May 26, 2017

Also see #14651 (comment)

@mhegazy
Copy link
Contributor

mhegazy commented May 26, 2017

And #15479

@azarus
Copy link
Author

azarus commented May 27, 2017

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
Copy link
Contributor

mhegazy commented May 30, 2017

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
Copy link
Author

azarus commented May 30, 2017

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

@mhegazy
Copy link
Contributor

mhegazy commented Jun 14, 2017

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

@mhegazy mhegazy closed this as completed Jun 14, 2017
@azarus
Copy link
Author

azarus commented Jun 15, 2017

Just lol.

@azarus
Copy link
Author

azarus commented Jun 15, 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.

@prograhammer
Copy link

prograhammer commented Nov 25, 2017

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
Copy link

vladimiry commented Nov 25, 2017

@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
Copy link

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

@vladimiry
Copy link

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
Copy link

@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
Copy link

alvis commented Jan 30, 2018

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
Copy link

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.

@microsoft microsoft locked and limited conversation to collaborators Jul 31, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

7 participants