Different Declaration output for same code from js and ts file

[daKmoR]

Bug Report

🔎 Search Terms

• declaration import rewrite
• declaration import change

🕗 Version & Regression Information

• Probably has always been like that (verified it in 4.9, 4.8, 4.7)

⏯ Playground Link

Sadly not possible as it's about importing of "nested" dependencies.

So I created a reproduction repository

1. Clone https://github.com/daKmoR/tsbug-declaration-output
2. Run npm install
3. Run npm run types
4. Inspect the output in dist-types

💻 Code

When creating types from a ts source file it keeps the import pathes as is. (which is expected)

👉 Source: src/ElementA.ts

import { LitElement } from "lit";
export class ElementA extends LitElement {}

👉 Output: dist-types/src/ElementA.d.ts

import { LitElement } from "lit";
export declare class ElementA extends LitElement {}

When creating types from "the exact same file" but as a js it changes the import pathes by "resolving" them.

👉 Source: src/ElementB.js

import { LitElement } from "lit";
export class ElementB extends LitElement {}

🙁 Actual behavior

👉 Output: dist-types/src/ElementB.d.ts

export class ElementB extends LitElement {}
import { LitElement } from "lit-element/lit-element.js";

🙂 Expected behavior

export class ElementB extends LitElement {}
import { LitElement } from "lit";

Consequences

Because of the miss match between the "location" of LitElement TS believes those are different LitElement types.

[RyanCavanaugh]

I think I understand why this is happening, but it seems super undesirable.

[fatcerberus]

Why is TS changing the import specifier? That should never happen.

[daKmoR]

Is there anything we can do to help? is the reproduction good enough?

in the meantime we found a "worse" example

// 
// input (simplified)
// 
import { Constructor } from '@open-wc/dedupe-mixin';
import { LitElement } from 'lit';
import { LocalizeMixinHost } from '@lion/ui/types/localize.js';

export declare class IngFieldHost { /* ... */ } 

declare function IngFieldMixinImplementation<T extends Constructor<LitElement>>(
  superclass: T,
): T &
  Constructor<IngFieldHost> &
  Pick<typeof IngFieldHost, keyof typeof IngFieldHost> &
  Constructor<LocalizeMixinHost> &
  Pick<typeof LocalizeMixinHost, keyof typeof LocalizeMixinHost> &
  Pick<typeof LitElement, keyof typeof LitElement>;
export type IngFieldMixin = typeof IngFieldMixinImplementation;  

// 
// output (simplified)
// 
export type IngFieldMixin = import('./types/IngFieldMixinTypes.js').IngFieldMixin;
export const IngFieldMixin: <
  T extends import('@open-wc/dedupe-mixin').Constructor<import('lit').LitElement>,
>(
  superclass: T,
) => T &
  import('@open-wc/dedupe-mixin').Constructor<
    import('./types/IngFieldMixinTypes.js').IngFieldHost
  > &
  Pick<typeof import('./types/IngFieldMixinTypes.js').IngFieldHost, 'prototype' | 'properties'> &
  import('@open-wc/dedupe-mixin').Constructor<
    import('../../../../node_modules/@lion/ui/dist-types/exports/types/localize.js').LocalizeMixinHost
  > &
  Pick<
    typeof import('../../../../node_modules/@lion/ui/dist-types/exports/types/localize.js').LocalizeMixinHost,
    'prototype' | 'localizeNamespaces' | 'waitForLocalizeNamespaces'
  > &
  Pick<
    typeof import('lit').LitElement,
    | 'prototype'
   // [...]
  >;

seems potentially related as its resolving a path again... but as it's a monorepo it does go pretty badly 😅

e.g. to highlight the issue

// input
Constructor<LocalizeMixinHost> 

// expected
import('@open-wc/dedupe-mixin').Constructor<
  import('@lion/ui/types/localize.js').LocalizeMixinHost
>

// actual
import('@open-wc/dedupe-mixin').Constructor<
  import('../../../../node_modules/@lion/ui/dist-types/exports/types/localize.js').LocalizeMixinHost
>

we currently "postprocess" the generated *.d.ts files to "fix" it 😅 would be nice if we could get rid of this "workaround" 🙏

again if there is anything we can do to prepare this more please let us know 🤗

[okadurin]

The issue is still valid and the actual behaviour part is reproducible