Module path maps are not resolved in emitted code

[mika-fischer]

TypeScript Version: 2.0.2

Code

tsconfig.json

{
    "compilerOptions": {
        "target": "ES6",
        "module": "commonjs",
        "baseUrl": ".",
        "paths": {
            "foo/*": ["*"]
        }
    }
}

app.ts

import {Foo} from 'foo/utils';
console.log(Foo);

utils.ts

export const Foo = 'Foo';

Expected behavior:

% ./node_modules/.bin/tsc && node app.js
Foo

Actual behavior:

% ./node_modules/.bin/tsc && node app.js
module.js:457
    throw err;
    ^

Error: Cannot find module 'foo/utils'
    at Function.Module._resolveFilename (module.js:455:15)
    at Function.Module._load (module.js:403:25)
    at Module.require (module.js:483:17)
    at require (internal/module.js:20:19)
    at Object.<anonymous> (/home/mfischer/src/videmo/tsc-test/app.js:2:17)
    at Module._compile (module.js:556:32)
    at Object.Module._extensions..js (module.js:565:10)
    at Module.load (module.js:473:32)
    at tryModuleLoad (module.js:432:12)
    at Function.Module._load (module.js:424:3)

app.js

"use strict";
const utils_1 = require('foo/utils');
console.log(utils_1.Foo);

Typescript is finding the right module, but in the emitted code, the module path is left as-is instead of applying the path aliases from tsconfig.json. Obviously node has no idea where to find the module. I would have expected typescript to resolve the module path and replace it with something that node can resolve.

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

[mhegazy]

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?

[kitsonk]

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.

[mika-fischer]

@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?

[vladima]

yes, this was the intent - to mitigate the mismatch between runtime and design time experience when module (as it is written by user) can be resolved in runtime but failed to be found by the compiler. At this point compiler always assumes that module id provided by the user is correct and never tries to change it.

[mhegazy]

similar response #9910 (comment)

[mika-fischer]

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.

[papercuptech]

Appreciating TS's position, here's a simple solution to the 90% use case for those of us using node, but wanting the convenience of using baseUrl relative require() calls without any fuss.

This solution hooks node's require() call, and resolves requests using the dirname of "main" to mimic baseUrl. It therefore assumes the baseUrl compiler option was also set to the same directory where the source "main.ts" was located.

To use, paste this tiny chunk of code at the top of your "main.ts".

import * as path from 'path'
import * as fs from 'fs'
(function() {
  const CH_PERIOD = 46
  const baseUrl = path.dirname(process['mainModule'].filename)
  const existsCache = {d:0}; delete existsCache.d
  const moduleProto = Object.getPrototypeOf(module)
  const origRequire = moduleProto.require
  moduleProto.require = function(request) {
    let existsPath = existsCache[request]
    if(existsPath === undefined) {
      existsPath = ''
      if(!path.isAbsolute(request) && request.charCodeAt(0) !== CH_PERIOD) {
        const ext = path.extname(request)
        const basedRequest = path.join(baseUrl, ext ? request : request + '.js')
        if(fs.existsSync(basedRequest)) existsPath = basedRequest
        else {
          const basedIndexRequest = path.join(baseUrl, request, 'index.js')
          existsPath = fs.existsSync(basedIndexRequest) ? basedIndexRequest : ''
        }
      }
      existsCache[request] = existsPath
    }
    return origRequire.call(this, existsPath || request)
  }
})()

[Parziphal]

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"
}

[jbgraug]

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%20docs does not say a thing about having to use "loaders that allow remapping" whatsoever.

[duffman]

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

[mattyclarkson]

@ef-carbon/tspm

[DanyelMorales]

Also you can try "momothepug/tsmodule-alias" to alias path resolution:

https://www.npmjs.com/package/@momothepug/tsmodule-alias

[BorntraegerMarc]

Only https://www.npmjs.com/package/module-alias worked for me...

[edufschmidt]

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?

[DanyelMorales]

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 <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKT9JWIkb0Wekz0H_Z3zKXvoE-49EIBks5t4EzkgaJpZM4J6vZQ> .

[edufschmidt]

Thanks @DanyelMorales, this is really handy.

[DanyelMorales]

you're welcome! :) 2018-05-31 16:35 GMT-05:00 edufschmidt <notifications@github.com>:

…

Thanks @DanyelMorales <https://github.com/DanyelMorales>, this is really handy. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKT9GNo30wNv4ZWzSwm_Lv4vesLPI3xks5t4GIzgaJpZM4J6vZQ> .

[robertmain]

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?

[tommedema]

How should one do relative path mapping for things that are NOT modules, i.e. not imports?

In a node script that reads a certain directory relative to the source file I used to do:

const starterDir = path.resolve(__dirname, './templates/starter')

since typescript compiles the script and writes it to another directory (based on config), __dirname will no longer lead to the above path resolving. What would be a solution to this?

[kitsonk]

How should one do relative path mapping for things that are NOT modules, i.e. not imports?

That is really "how do I use Node.js and TypeScript question" and much better asked in Gitter.im or StackOverflow.

[timkendall]

I love TypeScript but this is insanity.

[jpike88]

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.

[DanyelMorales]

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 <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKT9DD_z4KOHpfwddTomMXujEsza9tQks5uc0jbgaJpZM4J6vZQ> .

[squidfunk]

+1!

[duffman]

And it is generating executable code if you don´t use features which is unsupported by JavaScript Engines, that should make a lot of sense right there, for example: would you blame the C++ compiler if your application uses dynamic link libraries and that the program won´t run on a machine that doesn´t have these installed? 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! Don´t use them if you don´t understand how to set up a working environment, I really don´t think that this is Microsoft's responsibility here, they provided a feature and here´s how it works, it may not work as you want it or expect it to work but that does not make it wrong! Also, I´m curious, are you seriously letting this hinder you from developing using TypeScript? Den mån 14 jan. 2019 kl 21:34 skrev Robert Main <notifications@github.com>:

…

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? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_7FeuOJAnI9bXYSVgf_YghJluTyGks5vDOnEgaJpZM4J6vZQ> .

[fabiospampinato]

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.

[robertmain]

And it is generating executable code if you don´t use features which is
unsupported by JavaScript Engines,

I've always understood that TypeScript was supposed to compile to JavaScript. If you're telling me that certain features are not supported by JavaScript engines then why exactly are they there?

would you blame the C++ compiler if your application dynamic link libraries and that the program won´t run on a machine doesn't have these installed?

No, but I would blame it if it let me link to other C++ code that didn't actually exist with no compiler error or warning.

[duffman]

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 <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_zuWKV0qzzWt6_jZNgDLFt1TA0tMks5vDU3vgaJpZM4J6vZQ> .

[duffman]

They are there since Loaders use Path Mapping, that´s why it´s supported! And since you insist (like me) on using them without a Loader, what is the problem with using a tool so that you can make use of the feature? Den tis 15 jan. 2019 kl 05:10 skrev Robert Main <notifications@github.com>:

…

And it is generating executable code if you don´t use features which is unsupported by JavaScript Engines, I've always understood that TypeScript was supposed to compile to JavaScript. If you're telling me that certain features are not supported by JavaScript engines then why exactly are they there? would you blame the C++ compiler if your application dynamic link libraries and that the program won´t run on a machine doesn't have these installed? No, but I would blame it if it let me link to other C++ code that didn't actually exist with no compiler error or warning. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_25-ZmS235i1Ic7mvSzEt2QJDX6Bks5vDVTAgaJpZM4J6vZQ> .

[robertmain]

Look, I see your point. I do. But part of the compilers job is to sanity check things one last time. At best code that compiles but doesn't run is inconsistent behavior and when I first read into this issue the documentation seemed to suggest behavior that clearly isn't there

[duffman]

Please point me to that section of the documentation. tis 15 jan. 2019 kl. 05:31 skrev Robert Main <notifications@github.com>:

…

Look, I see your point. I do. But part of the compilers job is to sanity check things one last time. At best code that compiles but doesn't run is inconsistent behavior and when I first read into this issue the documentation seemed to suggest behavior that clearly isn't there — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_8e5v8IV-ynmjRTeoC3cp5llwnsIks5vDVm8gaJpZM4J6vZQ> .

[sukovec]

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

[MikeMitterer]

@duffman Can't you see that people here just want this feature??? You are telling everyone that he/she is to stupid to understand how this "feature" should be used. OK - you can look at this that way but who knows - maybe it's the other way around...

[sukovec]

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++.

[DanyelMorales]

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 <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ACKT9OqexgOaHH1vDFuRcO7U_r2DEC23ks5vDdFbgaJpZM4J6vZQ> .

[duffman]

. 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.

[MrXyfir]

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.

[InvictusMB]

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"   
  ]
}

[ywwhack]

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 😞

[duffman]

I acknowledge this problem, I´m not sure I´ve been aware of this specific problem due to my own personal setup, or maybe I was :) it´s not a super heavy fix, the fix will simply be to simply (blindly) trust the distPath, which is actually less and more simple code than the current solution, I´ll try to have a fix available by tomorrow... Den mån 28 jan. 2019 kl 15:59 skrev 叶伟伟 <notifications@github.com>:

…

I just want to use typescript with absolute path, but seems i have to config webpack or babel or something, it's toooo hard to achive!!! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10866 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAy_1_T-An7swSND-xdBhL0HNHxQkm6ks5vHxBggaJpZM4J6vZQ> .

[eps1lon]

Leaving this here because an actual documented use case for the current behavior of paths was not mentioned in this thread: @types/ packages do not backport features with regards to semver. They do however include updated types for older APIs that I can use. E.g. I'm using history@2 when history@3 is the latest.

"paths": {
    "history": [ "history/v2" ]
}

The compiler would need an extra option to differentiate between type aliases and "code" aliases. If we change the behavior to actually emit the path aliases then we need to add the ability to the compiler to find the correct types version.

This is not an argument against the proposed behavior. I'd rather have emitted aliases and just™ working solution for versioning of types. Just wanted to provide some context why changing this might not be as trivial as people think it is.

[cruhl]

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"?!?!

[cruhl]

I'm sorry to have sounded so frustrated in my comment, but the community's views here are seemingly being ignored and downplayed repeatedly.

[cruhl]

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

[kitsonk]

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.

[dwjft]

@kitsonk everything you just said is way off the mark.

The issue is that TS will operate one way during development / testing, and another after compilation has completed.

If TS wants to be a module resolver, it needs to choose a pattern and stick to it. If I run something with ts-node it should operate exactly as if I compiled some TS and ran it with node.

It does not, and that is the problem.

[DanielRosenwasser]

Maybe module maps will alleviate the frustration in the future. But our position here along with the technical problems we want to solve are pretty explicit - path mapping reflects the behavior of an external resolution scheme (e.g. path mapping in AMD and System.js, aliases in Webpack and other bundlers). It doesn't imply we will change your paths.

I don't think any recent discussion has been constructive recently, nor do I foresee any future changes here, so I'm going to lock this issue.