Module resolution strategy for libraries created in Typescript

[davnn]

It would be great if you could use absolute paths when creating reusable Typescript libraries, but as of now it looks like Typescript code with absolute paths is not easily reusable by other projects as every consumer would have to map the absolute paths to relative ones.

TypeScript Version: 2.0.3

Say you have a tsconfig as follows:

{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "baseUrl": "./src",
        "outDir": "lib"
}

The project is structure like this:
tsconfig.json
src/

• core
• test
• helpers

Inside your library you can now import modules as follows:

import * as X from "core/X";

Actual behavior:
Compiled with tsc your commonjs modules now reference "core/X" and consumers of your library don't know where to find "core/X", the same is true for declaration files.

Expected behavior:
You can either let tsc convert absolute paths to relative ones or provide an exportable path mapping.

From issue 5039:

The compiler does not rewrite module names. module names are considered resource identifiers, and are mapped to the output as they appear in the source

That means rewriting to relative paths is no option, what is the option then?

[mhegazy]

That means rewriting to relative paths is no option

why is that? what is write import * as X from "./core/X" ?

[davnn]

You mean that you just should not use absolute paths for code that is going to be published somewhere?

[kitsonk]

UMD declaration files allow relative imports. It is only global/ambient ones that do not. All of our (@dojo) distributable packages have relative mids in their .d.ts UMD files and it doesn't cause any problems consuming them downstream.

[mhegazy]

You mean that you just should not use absolute paths for code that is going to be published somewhere?

How is your library going to be used?

[davnn]

How is your library going to be used?

Compiled with TSC as "module": "commonjs", published via NPM and then imported in other nodeJS projects, but that does not work if the library uses absolute paths.

[mhegazy]

then do not use baseUrl. baseUrl is useful for AMD scenarios where you have a release process that "merges" all modules into one location. in node, there is a well-established concept of modules, packages, and module references.

if you are using node packages, use relative imports for files within your package, and non-relative (i.e. do not start with ./ or ../, e.g. "rx/lite" or "express") for modules you get from other packages.

[davnn]

Alright then, thank you very much.