TypeScript: Module path maps are not resolved in emitted code

Can someone tell me what the point of this feature is if the pathnames emitted are actually incorrect? That is to say, if the TypeScript compiler is happy with it, but the end result isn’t runnable - what’s the use case for this feature?

I love TypeScript but this is insanity.

All right, thanks. It might be useful to document this better in order to prevent more people from being confused. I now use https://www.npmjs.com/package/module-alias to make it work with node.

Can this not just be added as a compiler option? Clearly it’s a popular request. Knowing nothing of the workings of the compiler, shouldn’t implementing it be super simple? Why force us to jump through hoops elsewhere when it can be so easily solved directly with the TypeScript compiler, where it makes the most sense?

I’m a little confused on this issue. It has been closed and labelled ‘Working as Intended’. Am I to understand Typescript is intended to output invalid source? Seems odd.

Beggars can’t be choosers, but using Typescript avoids many frustrating aspects of vanilla JS and I count relative imports (‘…/…/…/…/…/utils/parser’) to be one of them. It would be amazing if Typescript could clean these up!

If this behavior is intended, then how can the path maps be used to solve the relative-import-hell in conjunction with node?

Well and to add context, "paths" is designed for use with loaders that allow remapping, unlike the Node.js require(). The intended behaviour is to allow TypeScript to resolve type information for various module IDs used by various loaders, not to rewrite module IDs. Basically it doesn’t do what you thought it did. Nor should it in my opinion, it should only have the capability to mirror the resolution strategies of loaders.

Summoning the top five TypeScript contributors: @ahejlsberg @andy-ms @DanielRosenwasser @sandersn @sheetalkamat

Could the TypeScript team reconsider this issue? I think this thread offers some useful discussion on both viewpoints and given its recent popularity and the amount of time that’s passed it should be looked at again.

Well and to add context, “paths” is designed for use with loaders that allow remapping, unlike the Node.js require(). The intended behaviour is to allow TypeScript to resolve type information for various module IDs used by various loaders, not to rewrite module IDs. Basically it doesn’t do what you thought it did. Nor should it in my opinion, it should only have the capability to mirror the resolution strategies of loaders.

Got here after wasting some time trying to set it up in a big project. If this behaviour is not going to change the least you could do is to update the documentation before closing this issue. The official documentation https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping docs does not say a thing about having to use “loaders that allow remapping” whatsoever.

@mhegazy Can you or someone else let us know if now two years later maybe the TypeScript team would possibly take a look at this again and reconsider?

If you’re going to use the module-alias package that mika-fischer mentioned, note that the paths you register to the package shouldn’t end in /, and the paths are relative to the path where package.json is (it may be obvious but it’s good to get it clear),

So if you have this in your tsconfig file:

"outDir": "./dist",
"baseUrl": ".",
"paths": {
  "foo/*": ["./src"]
}

You have to register this in your package.json:

"_moduleAliases": {
  "foo": "dist"
}

@mhegazy I expected it to work directly with node. It’s for a backend application. Is @kitsonk correct in stating that this is working as intended and typescript will not rewrite module paths?

@codeitcody Seems like it. It’s dumb that it would output something that simply doesn’t work without some third-party package but that’s the reality.

This issue has been around for 2 years and has no official word on whether it’s going to be implemented or not.

Considering this is required and basic functionality to use one of the best features of TypeScript in your Node.js projects, it’s pretty awful how it is being treated.

Do you use some other bundling tool like browserify or webpack on the generated output? or do you expect this to run directly on node?

We had the same problem at Dropbox and open-sourced this transformer https://github.com/dropbox/ts-transform-import-path-rewrite

@duffman

The aliases are interpreted by the TypeScript compiler, it compiles exactly as it should, it should most definitely not poke around in the resulting javascript, if you want to use aliases you will have to solve this yourselves!

Highly disagree. Unless you were joking, I really couldn’t tell.

TypeScript should compile code that works without needing a third-party tool to complete the job that was only partially implemented into the native compiler.

I seriously don´t understand why this thread goes on and on and on… We all know about the “path hell”, and that you (by using aliases) can really clean up that mess, everyone in this thread knows this!

The aliases are interpreted by the TypeScript compiler, it compiles exactly as it should, it should most definitely not poke around in the resulting javascript, if you want to use aliases you will have to solve this yourselves!

…or start threads at Apple, Google and Microsoft asking them to implement functionality in their JavaScript engines so that they can interpet your aliases 😉

The TypeScript compiler does exactly what it should do!

If you are working in the Angular world the road is paved, if you want to run your code directly in Node you will need a tool to resolve the paths, and I have made such tool just for you, it´s been used in production for over a year now, it´s being used by the largest newspaper here in Sweden, I made this so that you can go bare bone with Node, I´m not trying to sell anything here, I don´t make money from this 😃

And yes, there are tools like “tsmodule-alias” and similar hacks, you can actually make it work if you are very very careful, but it´s a mess, there are workarounds using ts-node, shell scripts etc etc…yadda yadda

I finally felt that enough is enough so I locked myself away and made TsPath the compile time aliases

#> npm install -g tspatj #myproject> tsc #myproject> tspath

or

#myproject> tspath --f headless (proved very useful on the build server)

and then you´re done, your javascript files now have the correct relative paths, isn´t that what we want here?

Cheers! 😃

https://www.npmjs.com/package/tspath

Den sön 13 jan. 2019 kl 22:20 skrev Fabio Spampinato < notifications@github.com>:

Just stumbled upon this, sometimes TypeScript can be a real pain in the ass.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-453866553, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAy_7JYrwYo3KOLxpLWP0np5JVz2kQzks5vC6MogaJpZM4J6vZQ .

Welcome to the club @def14nt. We’re a happy group of dreamers, starry-eyed as we gaze into a better future, patiently awaiting the day when TypeScript will implement the simple and sensible compiler option to make our lives easier. When that day finally is upon us, be sure to check the sky for the portly pink bodies of the pigs as they majestically fly away into the sunset on their newfound wings.

I don’t get it. Even with me knowing little about the TS codebase, this shouldn’t be hard to implement. I’ve just started using a shared project with client and server… why does TS present the paths functionality in the first place, then makes me jump through hoops to actually use it? Why does TS assume that I want to use a bundler/loader with every project I make? I’m trying to use TS to simplify my projects, not tack on more tooling libraries to compensate for a 90% implemented TS feature.

I just want to use typescript with absolute path, but seems i have to config webpack or babel or something, it’s too hard to achieve this simple feature, it should be easier 😞

You really don´t understand this, do you? The code is not broken, if it´s broken it is because you have configured the compiler to generate code that your “platform” does not support, in this case, aliases!

In your case, don´t use aliases, “you” don´t support them, seriously!

Even if this would be a 1 line fix (of course that´s not the case) it´s a matter of what a compiler should and should not do! This feature has been added in order to SUPPORT LOADERS not the other way around, read up on Path Mapping in the official documentation, so again, you are using it wrong!

Again, this feature is for Loaders/Resolvers, you have misunderstood how it works, so no, Microsoft should not alter the compiler so that you can paste aliases without an environment that supports it!

Den tis 15 jan. 2019 kl 04:41 skrev Fabio Spampinato < notifications@github.com>:

This is a feature that can be utilized if you manage the relative paths, take responsibility for them like Angular does with WebPack or as I do with all my TypeScript projects with TSPath!

This is a feature which makes the compiler output broken code, code that could be working if they only wrote 1 line of code for resolving those paths.

The fact that TS needs an external bundler just so that the outputted code can be executed is plain ridiculous.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454256799, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ .

This is a feature that can be utilized if you manage the relative paths, take responsibility for them like Angular does with WebPack or as I do with all my TypeScript projects with TSPath!

This is a feature which makes the compiler output broken code, code that could be working if they only wrote 1 line of code for properly resolving those paths.

The fact that TS needs an external bundler just so that the outputted code can be executed is plain ridiculous.

The TypeScript compiler does exactly what it should do!

If this thread was full of people requesting that tsc also do minification or some such, I’d agree with you. However it isn’t. It’s people requesting that the compiler generate executable code. I really don’t think that’s too much to ask from a compiler, do you?

install and run “tspath” in your project folder… https://www.npmjs.com/package/tspath

The status of this issue left me no other choice but to demote TS to type checker duty only. Babel now has a decent support for TS syntax and together with babel-plugin-module-resolver does the job of emitting working code for this use case just fine. The only downside is duplicating bits of configuration from tsconfig.json as Babel does not care about TS configs. But it is an acceptable price for working absolute paths in node projects and as a bonus I get the whole ecosystem with brilliant things like babel macros.

This is the minimum setup I got working as a drop in replacement for tsc compiler:

• npm install --save-dev @babel/cli @babel/core @babel/preset-env @babel/preset-typescript babel-plugin-module-resolver @babel/plugin-proposal-class-properties @babel/plugin-proposal-object-rest-spread
• in package.json: tsc -> tsc && babel ./src --out-dir ./dist --extensions ".ts,.js"
• in tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@mynamespace/*": ["src/*"]
    },
    "outDir": "./dist",
    "noEmit": true, <--
    "allowJs": true,
    "target": "ES2017",
    "module": "CommonJS",
    "lib": [
      "ES2017"
    ]
  },
  "include": [
    "./src/**/*"
  ]
}

• in .babelrc:

{
  "presets": [
    "@babel/preset-typescript",
    ["@babel/preset-env", {
      "targets": {
        "node": true
      }
    }]
  ],
  "plugins": [
    ["module-resolver", {
      "root": ["./src"],
      "alias": {
        "@mynamespace": "./src"
      },
      "extensions": [".js", ".ts"]
    }],
    "@babel/plugin-proposal-class-properties",
    "@babel/plugin-proposal-object-rest-spread"   
  ]
}

This feature has been added in order to SUPPORT LOADERS not the other way around, read up on Path Mapping in the official documentation, so again, you are using it wrong!

https://austinknight.com/wp-content/uploads/2015/04/DesignVSUX.jpeg

Please help to upvote this post on Reddit: https://www.reddit.com/r/typescript/comments/a07jlr/path_maps_cannot_be_resolved_by_tsc_works_as/ Don’t know why it needs this huge discussion here. It should be easy to solve this bug. An option in tsconfig and everyone can decide if he want’s the current behavior (for whatever reason) or a working approach.

Well, isn’t this a nice problem to fall upon.

It does seem very counterproductive to have a feature that essentially renders your app unusable without jumping through hoops (i.e installing more dependencies to workaround the issue).

@ef-carbon/tspm

. TS is not assembly language, not even a C/C++.

I really don´t understand what you are trying to point out by establishing that TS is not C++, most of us are well aware of that I think!

We have also established that alias/path mapping is used in production all over the world, so naturally, VS Code should support that, but it´s still not an argument for MS to craft the compiler to suit your setup!

What I´m having a hard time understanding is why you keep at it, the compiler works as it´s supposed to work, again, read the docs which clearly states what the feature is for!

I mean you can set up a working TS development environment with path aliases in like 2 minutes, if you don´t want to use WebPack, you can use TSPath to resolve all paths in all js files in 1 second, add it to the package.json as a run script and you don´t even have to think about it, the problem does not exist, the compiler stays the way it was meant to function and you can carry on happy hurray!?

Or if it is so important to you that the actual compiler does this for you, then I suggest you fork the compiler and implement it yourself, maybe it would be a big hit or maybe people are happy the way they are since they have set up their environments to support aliases.

I understand your frustration, but lots of people feeling a behaviour is correct, doesn’t mean it is the right thing to do.

TypeScript rewriting module identifiers is a slippery slippery slope. What has been expressed multiple times in this thread is that TypeScript is configurable to model the behaviour of other module resolvers and other build tools, not replace or implement them.

Just because TypeScript can be configured to resolve modules in flexible ways doesn’t not mean that TypeScript emits “broken code”. Certain loaders and bundlers that mirror this configuration would work just fine.

If we were to be critical of anything, we could blame the team for naming the option something that might look like it fixes a problem it was never intended to fix, though the documentation for the option makes it clear that it does not change the emit.

Because a particular tool doesn’t solve a problem you have doesn’t always mean it is that tools fault. It maybe you are just don’t have all the tools you need to solve your problem.

I’ve created a compile-time solution where you can continue using tsc. https://github.com/joonhocho/tscpaths

Microsoft/TypeScript#15479 (comment)

+1!

Take a look at https://github.com/momoThePug/tsmodule-alias

2018-05-31 15:04 GMT-05:00 edufschmidt notifications@github.com:

I too managed to get this working with module-alias, with the downside that I have to keep track of my aliases both within tsconfig.json and package.json. Has anyone found a simpler solution?

The solution pointed out by @mattyclarkson https://github.com/mattyclarkson also works, but I couldn’t find a way of using it side-by-side with ts-node. Any ideas?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-393662306, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ .

similar response https://github.com/Microsoft/TypeScript/issues/9910#issuecomment-234729007

Just look at how many times this has been referenced… What a waste of time and attention for so many people.

For the second time during a company-wide TS workshop, I’ve had to explain this inane and embarrassing behavior…

Seriously!

What kind of language compiler, especially one whose primary sales pitch is more correctness for JavaScript, produces broken code as a “feature”?!?!

Development team should add support for alias resolution. I suggest add a key for compiler resolution in tsconfig.

It would be nice Microsoft!!!

We beg you, we need your help to improve applications with alias.

😦 everybody here is sad and angry(, and hungry) because of lag of consistency. Typescript is awesome, I love it…

We Love it!

Best regards a Homeless developer…

El mar., 15 de ene. de 2019 08:02, Mike S. notifications@github.com escribió:

By the way, my opinion is following:

Aliases are builtin in compiler a compilation is OK. It may make users think, that it should work like they think (and this issue is pretty much good proof it’s true). It seems illogical - why something works in “official” editor (vscode - especially when using “auto import” feature, vscode uses aliased path), why copiler also works OK, when resulting code is not working? Saying “js engine don’t support it” makes me wanting to ask even more - wasn’t TS meant as a thing to mitigate some of JS “problems”?

I would expect one of two solutions of this:

1. Correctly overriding imports with aliases
2. Showing a warning

Saying “it’s correct behavior” is, I think, wrong. It’s not. TS is not assembly language, not even a C/C++.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-454384357, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ .

By the way, my opinion is following:

As aliases are builtin in compiler and compilation of project with them is OK. It may make users think, that it works way it’s suggesting (and this issue is pretty much good proof I’m right). It even seems illogical - why something works in “official” editor (vscode - especially when using “auto import” feature, vscode uses aliased path), why copiler also works OK, when resulting code is not working? Saying “js engine don’t support it” makes me wanting to ask even more - wasn’t TS meant as a thing to mitigate some of JS “problems”?

I would expect one of two solutions of this:

1. Correctly overriding imports with aliases
2. Showing a warning

Saying “it’s correct behavior” is, I think, wrong. It’s not. TS is not assembly language, not even a C/C++.

I agree with you. I think, TS was developed for frontend, 'cause webpack already implements quite well ts alias paths, and with Requirejs is also the same thing. But for Nodejs projects it’s so hard. 😦

El jue., 20 de sept. de 2018 02:50, Josh Pike notifications@github.com escribió:

I don’t get it. Even with me knowing little about the TS codebase, this shouldn’t be hard to implement. I’ve just started using a shared project with client and server… why does TS present the paths functionality in the first place, then makes me jump through hoops to actually use it? Why does TS assume that I want to use a bundler/loader with every project I make? I’m trying to use TS to simplify my projects, not tack on more tooling libraries to compensate for a 90% implemented TS feature.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Microsoft/TypeScript/issues/10866#issuecomment-423077950, or mute the thread https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ .

I too managed to get this working with module-alias, with the downside that I have to keep track of my aliases both within tsconfig.json and package.json. Has anyone found a simpler solution?

The solution pointed out by @mattyclarkson also works, but I couldn’t find a way of using it side-by-side with ts-node. Any ideas?