Module path maps are not resolved in emitted code

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?

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?

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.

Mohamed Hegazy (@mhegazy)

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

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.

similar response #9910 (comment)

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.

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)
  }
})()

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

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.

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

@ef-carbon/tspm

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

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

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

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

Anders Hejlsberg (@ahejlsberg)

Summoning the top five TypeScript contributors: Anders Hejlsberg (@ahejlsberg) Andy (Andrewkraft) (@Andy-MS) Daniel Rosenwasser (@DanielRosenwasser) Nathan Shively-Sanders (@sandersn) Sheetal Nandi (@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.

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

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 😞

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

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.

https://github.com/Microsoft/TypeScript/issues/10866

Add option path mapping

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

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

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

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.

Kitson Kelly (@kitsonk)

Kitson Kelly (@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.

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.

Navigation Menu

Repository navigation

Module path maps are not resolved in emitted code #10866

53 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Module path maps are not resolved in emitted code #10866

Description

Activity

mhegazy commented on Sep 13, 2016

kitsonk commented on Sep 13, 2016

mika-fischer commented on Sep 13, 2016

vladima commented on Sep 13, 2016

mhegazy commented on Sep 13, 2016

mika-fischer commented on Sep 14, 2016

papercuptech commented on Dec 20, 2016

Parziphal commented on Sep 6, 2017

jbgraug commented on Dec 12, 2017

duffman commented on Jan 14, 2018

mattyclarkson commented on Feb 6, 2018

0ct0d4n commented on Feb 22, 2018

BorntraegerMarc commented on May 1, 2018

53 remaining items

duffman commented on Jan 15, 2019

MrXyfir commented on Jan 15, 2019

InvictusMB commented on Jan 22, 2019

ywwhack commented on Jan 28, 2019

duffman commented on Jan 28, 2019

eps1lon commented on Feb 7, 2019

cruhl commented on Feb 14, 2019

cruhl commented on Feb 14, 2019

cruhl commented on Feb 14, 2019

kitsonk commented on Feb 14, 2019

dwjft commented on Feb 14, 2019

DanielRosenwasser commented on Feb 14, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions