TypeScript paths are not resolved in definition files #32999

alshdavid · 2019-08-21T01:30:56Z

TypeScript Versions: 3.5.3 and 3.7.0-dev.20190820

Search Terms:
typescript paths remain after compile in type definition files

Code

index.ts

export * from '~/b'

b.ts

export const myThing = 'Something'

tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "module": "es2015",
    "declaration": true,
    "outDir": "dist",
    "strict": true,
    "moduleResolution": "node",
    "baseUrl": "./",
    "paths": {
      "~/*": ["src/*"]
    }
  }
}

Expected behavior:

/dist/index.d.ts

export * from './b'

Actual behavior:

/dist/index.d.ts

export * from '~/b'

More Info:

My package.json has

{
    "main": "dist/index.js",
     "types": "dist/index.d.ts",
}

When someone imports the package, the types are broken because the paths don't resolve to the expected files.

Perhaps I am approaching this incorrectly. Is there an alternative method to deal with path resolution?

The text was updated successfully, but these errors were encountered:

RyanCavanaugh · 2019-08-21T17:14:44Z

This is the intended behavior. TypeScript's golden rule about import paths is never change what the user wrote; this applies both to .d.ts and .js outputs. This is the most predictable behavior and the most controllable from the dev side.

How you want to fix this really depends on why you wrote it as ~/b in the first place.

fatcerberus · 2019-08-21T18:09:47Z

never change what the user wrote

As an aside: While I agree with this approach on the whole, it is a problem specifically for file extensions: TS understands extensionless imports, but not all environments do. e.g. I believe Deno requires an extension, as do browsers, and there's no way to deal with this discrepancy on the TS side--paths doesn't help here. (TS does understand imports ending in .js, but not e.g. .mjs--and auto-import always omits the extension).

alshdavid · 2019-08-21T23:46:01Z

How you want to fix this really depends on why you wrote it as ~/b in the first place.

A nice default I use for projects is set ~ as the src directory, allowing for the use of absolute imports.

import env from ~/environment`

vs

import env from '../../../environment'

When using absolute paths in a library which is intended to be hosted in npm, the absolute paths no longer register as the application is compiled into a different folder.

Should I set my tsconfig.compilerOptions.path to { "~/*": ["./src/*", "./dist/*" ]

weswigham · 2019-08-21T23:49:22Z

You shouldn't use paths at all in that case - paths exists to instruct the compiler how the runtime is expected to interpret paths, not to dictate to TS how to rewrite them so they work at runtime.

alshdavid · 2019-08-22T01:03:54Z

Oh. So what is the intended use case for paths?

fatcerberus · 2019-08-22T01:07:47Z

paths is for when you have module paths that are already resolvable at runtime, but TS doesn’t understand them, so you can point the compiler to where it can find them.

It’s not an aliasing feature, sadly.

alshdavid · 2019-08-22T01:20:30Z

That's a bummer. Does the TS team have any plans to introduce an tsconfig.compilerOptions.aliases feature?

fatcerberus · 2019-08-22T01:27:32Z

Most likely not: #31643 (comment)

fatcerberus · 2019-08-22T01:32:42Z

For the record, your use case--sometimes wanting to use a rooted path instead of multiple levels of ../--is why I support the path form @/absolute/path at runtime in miniSphere. I wish it were possible to do the same in Node.js (rooted at the location of package.json, for example) but unfortunately it isn't 🙁

typescript-bot · 2019-08-24T20:00:07Z