Generated declaration files rewrite import paths

[eps1lon]

Bug Report

Originally reported in mui/material-ui#24112

🔎 Search Terms

declaration file relative import

Possibly related: #38111, #39695, #36763, #18311

🕗 Version & Regression Information

• This is the behavior in every version I tried (4.1.3, 4.2.0-dev.20201230), and I reviewed the FAQ for entries about: everything (could not find relevant entries)

⏯ Playground Link

Not applicable but I have a cloneable repro: https://github.com/eps1lon/ts-monorepo-type-import-paths

💻 Code

// styles/index.ts
export interface CSSProperties {
  [k: string]: unknown | CSSProperties;
}

export type StyleRules<ClassKey extends string = string> = Record<
  ClassKey,
  CSSProperties
>;
export function createStyles<ClassKey extends string = string>(
  styles: StyleRules<ClassKey>
): StyleRules<ClassKey> {
  return styles;
}


// core/index.ts
import { createStyles } from '@material-ui/styles'; 
export const styles = createStyles({
  root: {
    display: 'block'
  }
});

🙁 Actual behavior

Generated declaration file imports types via relative path ("../../styles/src").
This path is invalid once published to npm. I was under the impression the paths does not apply any rewrites (source: #25677 (comment))

// core/dist/index.d.ts
export declare const styles: Record<"root", import("../../styles/src").CSSProperties>;
//# sourceMappingURL=index.d.ts.map

🙂 Expected behavior (minimum viable)

Types are imported with the original identifier ("@material-ui/styles"). Otherwise they're unreachable once installed.

// core/dist/index.d.ts
export declare const styles: Record<"root", import("@material-ui/styles").CSSProperties>;
//# sourceMappingURL=index.d.ts.map

ideal expected behavior

// core/dist/index.d.ts
export declare const styles: import("@material-ui/styles").StyleRules<"root">;
//# sourceMappingURL=index.d.ts.map

This is the actual return type of createStyles. TypeScript should never inline types from libaries we import. Otherwise we need to re-build and publish everytime a dependent library changes their types.

[andrewbranch]

I believe this is a definite duplicate of #39117 (which was pointed out to be a probable duplicate of #38111). Does that seem like the same problem @eps1lon?

[eps1lon]

I believe this is a definite duplicate of #39117 (which was pointed out to be a probably duplicate of #38111). Does that seem like the same problem @eps1lon?

Definitely! Thanks for the pointers especially since they contain potential workarounds.

Closing in favor of #39117