declaration emit uses absolute path when inferring type

[eps1lon]

Bug Report

🔎 Search Terms

emit declaration path
Similar to #38111 but #38111 uses the same source for import whereas the repro here uses different import sources.

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________

⏯ Playground Link

Repro: https://github.com/eps1lon/ts-proj-references-abs-path-repro
Spans multiple files which is not suitable for Playground

💻 Code

useDialogNavigation.ts (emits expected package identifier import)

declare function useCallback<T extends Function>(callback: T): T;

import { navigateBack, close as _close } from "@klapp/navigation";

export const useDialogNavigation = () => {
  const close = useCallback(() => {
    return _close(null as any);
  });

  const back = useCallback(() => {
    return navigateBack(null as any);
  });

// expected
// back: () => import("@klapp/navigation").MightReturnComponentId
  return { back, close };
};

// useNavigationEvents.ts (emits unexpected path import)

import { useDialogNavigation } from "./useDialogNavigation";
export const useNavigationEvents = () => {
  const { back, close } = useDialogNavigation();

  return {
// unexpected
// back: () => import("packages/navigation").MightReturnComponentId
    back,
    close,
  };
};

// tsconfig.json

{
  "extends": "../../tsconfig.base.json",
  "include": ["./**/*"]
}

// tsconfig.base.json

{
  "compilerOptions": {
    "baseUrl": "./",
    "declaration": true,
    "moduleResolution": "NodeNext",
    "noEmit": false,
    "outDir": "./types/dist",
    "rootDir": ".",
    "strict": true
  }
}

🙁 Actual behavior

One file uses import("@klapp/navigation") while another uses import("packages/navigation")

🙂 Expected behavior

Both use import("@klapp/navigation")

[RyanCavanaugh]

Both packages/navigation and @klapp/navigation are legal ways to refer to that module, and declaration emit has no way to know which you wanted.

I'd recommend unsetting baseUrl in your tsconfig; this will make the first one illegal and cause the second to be emitted. Barring that, you'd need to have a manual import in that file to tell the emitter which you wanted.

[Andarist]

From baseUrl docs:

This resolution has higher priority than lookups from node_modules.
This feature was designed for use in conjunction with AMD module loaders in the browser, and is not recommended in any other context.

I can only second that. I had multiple terrible experiences with baseUrl in the past when somebody set this in tsconfig, likely just copy-pasting from another config. Perhaps it would be even best to add a prominent warning to the docs about this being a (sort of) legacy-ish feature?

[eps1lon]

baseUrl used to be required to work with paths pre 4.1 which is why we (and probably most) end up still having it.

It's also pretty easy to fall into the trap of adding baseUrl given the current error message when paths don't contain the leading ./: "Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?". It is not that surprising that people opt for the DRY baseUrl instead of repeating the leading ./.

Both packages/navigation and @klapp/navigation are legal ways to refer to that module, and declaration emit has no way to know which you wanted.

Then why does TypeScript then complain that it can't find the module at packages/navigation we it would use the mitted declaration in a composite project? It wouldn't be a problem per se since we don't ship these types. But the declarations emitted are used for incremental builds where TS specifically says "can't find module 'packages/navigation'". So I don't know what you mean with "legal way" because TypeScript itself cannot handle this emit using the same tsconfig. Which begs the question: Why not error when this option is set in conjunction with node-ish resolutions? What valid use case would there be for the tsconfig I shared?

[RyanCavanaugh]

Then why does TypeScript then complain...

If you take Project A under settings X, produce a .d.ts file, and try to consume it from Project B under settings Y, then it's entirely possible that differences between X and Y (or even file layout changes) mean that a module specifier that works in A doesn't work in B. packages/navigation works in this compilation so it's considered a legal path; knowing whether or not your downstream projects are configured in a way to also accept that path would require precognition.

[eps1lon]

It was emitted and consumed by the same project that used incremental builds. I reduced it to just highlight the incorrect emission.

[typescript-bot]

This issue has been marked as "Not a Defect" and has seen no recent activity. It has been automatically closed for house-keeping purposes.