Typescript: Emitted declarations files use new import() types syntax

Created on 14 Jun 2018 · 7Comments · Source: microsoft/TypeScript

TypeScript Version:

2.9.2
3.0.0-dev.201xxxxx

Search Terms:

declarations
import

Code
Taken from full repo

import ClassA from "./classA";
import enhance from "./enhance";

type Props = ClassA["props"];

const Enhanced = enhance<Props>(new ClassA({ foo: "1" }));
export default Enhanced;

Expected behavior:
Declarations are consumable by typescript < 2.9 if they are built from 2.9.2. I would expect breaking changes from 3.x but not 2.9.x

Actual behavior:
Declarations use new import() types syntax which throws errors in typescript < 2.9.

declare const Enhanced: (instance: import("./classA").Props & import("./enhance").WithEnhancement) => boolean;
export default Enhanced;

node_modules/library/lib/index.d.ts(1,42): error TS1005: ',' expected.
node_modules/library/lib/index.d.ts(1,54): error TS1005: ',' expected.
node_modules/library/lib/index.d.ts(1,61): error TS1005: ',' expected.
node_modules/library/lib/index.d.ts(1,98): error TS1005: ';' expected.
node_modules/library/lib/index.d.ts(1,100): error TS1128: Declaration or statement expected.

In my actual use case I encountered Property 'Example' does not exist on type 'Promise<typeof "PathToType'. though I could not reproduce this.

Playground Link:

Related Issues:

24848

Working as Intended

Source

eps1lon

👍1

All 7 comments

The same could be said about unique symbol, conditional types or any other type-level language feature introduced lately.
The compiler would need to know about all (or a certain subset of) previous versions of the compiler and the features they support.
In addition to that maintenance burden, you probably want API consumers with newer versions of TypeScript to use declaration files with the most recent features. That opens another can of worms, because you cannot ship multiple declaration files each targeting a different version of the compiler (there's already an issue for that with @types/ as the primary use case).

In my projects I typically require API users to use the latest version of TypeScript. If it works with older versions, that's great, but I don't support it.

The only alternative is you using the oldest version of TypeScript you want to support during development of your project.

ajafff on 14 Jun 2018

After thinking about this a bit more I came to the same conclusion. I basically have to pin my own typescript version unless I want to bump my major version every time I bump the minor version of typescript.

So updating typescript to a new minor version should be treated with caution if you want to avoid breaking changes in your library.

My main issue here is though that I'm not even using new features so I expected everything to work fine if I use new features only in files that are not shipped and for development purposes only. Might use different ts versions for development and build.

eps1lon on 14 Jun 2018

Adding an explicit type annotation on your declaration will avoid generating the new syntax in the output. we generally recommend pinning your TS version to major.minor.