TypeScript paths config doesn't work with leading slashes.

[trusktr]

TypeScript Version: 2.1.1 / nightly (2.2.0-dev.201xxxxx)

2.1.5

Code

app.ts

import Foo from '/common/Foo'
console.log(new Foo)

tsconfig.json

{
    "compilerOptions": {
        "paths": {
            "/common/*":  ["../../common/*"]
        }
    }
}

Filesystem:

website/
    common/
        Foo.js
    somewhere/
        project/
            tsconfig.js
            app.js

Expected behavior:

tsc should be able to recognize that when it sees a dependency like /common/Foo it should look for website/common/Foo.js in the filesystem.

Actual behavior:

It can't.

** More details **

I can get the following to successfully resolve files, by simply removing the leading slashes:

app.ts

import Foo from 'common/Foo'
console.log(new Foo)

tsconfig.json

{
    "compilerOptions": {
        "paths": {
            "common/*":  ["../../common/*"]
        }
    }
}

Filesystem:

website/
    common/
        Foo.js
    somewhere/
        project/
            tsconfig.js
            app.js

In this case, however, the output module contains something like

output.js

define(['common/Foo'], function(Foo) { /*...*/ })

But this is problematic, because if baseUrl in RequireJS config is set,

require.config({baseUrl: '/some/place'})

then RequireJS will look for the module at example.com/some/place/common/Foo.js which doesn't exist. I need it to look for the dependency at example.com/common/Foo.js, f.e. TypeScript would output the following including the leading slash:

output.js

define(['/common/Foo'], function(Foo) { /*...*/ })

It would be great if TypeScript could support this case, then the output can still have an absolute path and work as expected.

Unfortunately, RequireJS doesn't support map configs like the following:

require.config({
    baseUrl: '/some/place',
    map: {
        common: '../../common'
    }
})

I think solving this in TypeScript is the best options because then it can be taken advantage of in other environments besides RequireJS.

[trusktr]

Side note, I discovered that I was using RequireJS' map option wrong, so it is indeed possible to solve the problem in RequireJS:

require.config({
    baseUrl: '/some/place',
    map: {
        '*': {
            common: '../../common'
        }
    }
})

A TypeScript solution would still be nice.

[hexsprite]

I'm also having this problem when attempting to migrate my Meteor application to use TypeScript.

I have code like:

import { logger } from '/imports/logging'

Where Meteor maps /imports/logging to <srcdir>/imports/logging.js

Meteor doesn't use the RequireJS runtime so I don't have the ability to workaround like this.

My ideal would be to able to re-configure the root to my liking in tsconfig.json, ala: "absoluteRootPath": "./"

[mhegazy]

Leading slash refers to the root directory, so this is an absolute path. path mapping does not work on absolute or relative paths.

[hexsprite]

@mhegazy that's not compatible with Meteor JS which is a VERY popular Javascript application framework. (currently 38,469 stars on their GitHub Repo) https://github.com/meteor/meteor

all that would be required to solve this is a way to override the absolute path behavior for frameworks that desire it. The default could remain but just a flag as I described in my previous comment would work great.

[hexsprite]

@mhegazy here's some further info on how Meteor structures applications. https://guide.meteor.com/structure.html

[mhegazy]

it is not just a flag. it has implications on module names in output and generated declarations, which can then be consumed by third party apps.

The is really the same behavior as node today. / means the root.

[hexsprite]

This seems to go against the design goals of TypeScript because it introduces an opinion about import paths should be interpreted which is clearly not the same across all Javascript frameworks and platforms.

Bare node interprets it this way, sure, but many frameworks including the popular Meteor framework and also users of babel support mapping the leading slash to mean the project root not filesystem root.

Let's face it, importing a file from the filesystem root is about as useful as a caps lock key and we know many people remap that key as well.

And not that I think you should support everything that Flow does, but they also support mapping the leading slash to something else: https://www.npmjs.com/package/babel-plugin-root-import#dont-let-flow-be-confused

Here's some other examples of platforms that use the leading slash to mean something else:
https://www.npmjs.com/package/babel-root-slash-import

If you can't tell I REALLY want to use TypeScript on this project but this is a show-stopper. Thanks for considering this.

[mhegazy]

This seems to go against the design goals of TypeScript because it introduces an opinion about import paths should be interpreted which is clearly not the same across all Javascript frameworks and platforms.

This is about what a path means. we have mirrored the node module resolution in our module resolution strategy, and that is how @types\node\index.d.t.s works for instance. not sure why we should pick and chose what parts of the node module names is good and what is bad.

Here's some other examples of platforms that use the leading slash to mean something else:
https://www.npmjs.com/package/babel-root-slash-import

Here is you are expecting the compiler to rewrite your module name in the otuput. this is something the compiler does not do... it only needs to know where the file is, module names do not change.
Please see similar discussion in #18951 and #16640

[hexsprite]

Thanks for the extra details.

Actually, I just want the compiler to pass it through unchanged as Meteor in this case will properly interpret the paths in the resulting JS. It implements its own module loader.

I might have hijacked this thread a bit but ideally I just want TypeScript to find the files in the right location so that it can typecheck everything but I'm fine if it just passes the paths through unchanged and have the framework handle it at in its existing way at runtime.

So perhaps I should open a different issue for my case as it's somewhat different than the OP's issue (though related).

[mhegazy]

sure.

[mgrivera]

Hi @hexsprite,
have you opened that issue already. I am interested in this theme because, like you, I use meteor and VS code and typescript, and have been experiencing this problem myself. Bye ...

[trusktr]

@mhegazy

not sure why we should pick and chose what parts of the node module names is good and what is bad.

Hello Mohamed, you don't have to pick, you can let the end user pick by giving the user a configurable option. Then everyone will be happy doing it their own way.