In the generated description file, the module path needs to be modified to a relative path.

Search Terms

description file, paths, baseURL, relative path

Suggestion

In the case where compilation parameters --paths and --baseURL are enabled

#9910

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

The module names you write are not going to change in the output. the "paths" and "baseURL" are there to tell the compiler where they are going to be at runtime.

This will cause the generated description file to be invalid.

In most cases, --paths and --baseURL are used to facilitate the import of source code modules without the use of very awkward relative paths.

I think the description file needs to convert the path map into a relative path as much as possible. Because the description file does not have a runtime environment, and there is no special packaging tool.

---

Related bugs: Inferring the type generated description file, fixed issue with import path.

in typescript 3.0.1:
https://github.com/ZSkycat/issue-typescript-20180821/blob/b29f377029aa8d0b1022bd2f703a7773389a760b/dist/types/deep/deep/factory.d.ts#L3

in typescript 3.1.0-dev.20180818:
https://github.com/ZSkycat/issue-typescript-20180821/blob/master/dist/types/deep/deep/factory.d.ts#L3

Use Cases

https://github.com/ZSkycat/issue-typescript-20180821

This is a use case for packaging into a commonjs module using webpack.

path mapping config:

// webpack.config.js
resolve: {
    alias: {
        src: path.resolve('./src'),
    },
},

// tsconfig.json
"baseUrl": ".",
"paths": {
    "src/*": ["./src/*"],
},

This will cause the generated description file to be unusable.

https://github.com/ZSkycat/issue-typescript-20180821/blob/master/dist/types/deep/deep/factory.d.ts#L1

Examples

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript / JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. new expression-level syntax)