3.8 RC Regression? "Individual declarations in merged declaration"

[garrettm]

TypeScript Version: 3.8.1-rc and nightly (3.8.0-dev.20200207)

Search Terms:
Individual declarations in merged declaration

Code
Two files:

// ns.ts
export type Type = {greet: string}

export function hello(input: Type) {
  console.log(input.greet)
}

// use.ts
import * as Greeting from './ns'

export type Greeting = Greeting.Type
export {Greeting}

Expected behavior:
Expected that this compiles and users can refer to Greeting as both the type {greet: string} and the namespace of functions/data (just hello in this case). In versions 3.7.5 and 3.8.0-beta, this was OK.

Actual behavior:
3.8.1-rc and current nightly produce these errors:

use.ts:1:13 - error TS2395: Individual declarations in merged declaration 'Greeting' must be all exported or all local.

1 import * as Greeting from './ns'
              ~~~~~~~~

use.ts:3:13 - error TS2395: Individual declarations in merged declaration 'Greeting' must be all exported or all local.

3 export type Greeting = Greeting.Type
              ~~~~~~~~

[DanielRosenwasser]

@andrewbranch I thought this was a break in 3.7

[DanielRosenwasser]

We discussed it in #33422 and I'm pretty sure the relevant issue was #31231.

[andrewbranch]

@DanielRosenwasser it looks like #31231 simply failed to handle the combination of namespace import + type alias... 😱

[andrewbranch]

I guess we accidentally fixed that case, which we had previously accidentally left unfixed, sometime after the beta? Possibly with #36237? Sorry @DanielRosenwasser, I should have recognized #36237 as a breaking change 😕

[garrettm]

@andrewbranch @DanielRosenwasser this is working as intended? So, I'll need to change my code to upgrade to 3.8+?

[DanielRosenwasser]

Yes, I believe so. It's something I wish we could've communicated sooner, but the code never should have compiled.

[garrettm]

Okay, thanks. For the record, this pattern can be really useful in terms of exposing a type + a set of functions on that type.

You can do this with an explicit namespace in a file, but I thought that was not encouraged anymore. Like this:

export type Greeting = {greet: string}
export namespace Greeting {
  export function hello(input: Greeting) {
    console.log(input.greet)
  }
}

These seem isomorphic and it seems weird to allow one and not the other.

[andrewbranch]

@garrettm the issue isn’t with what will merge as exports, it’s that imports are never allowed to merge with local declarations. You could rewrite your original example as

// use.ts
import * as ns from './ns'

export type Greeting = ns.Type
export { ns as Greeting }

and that would be fine.

[garrettm]

@andrewbranch thanks! That worked.

[typescript-bot]

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[danprince]

@garrettm @andrewbranch Do you have an example of that rewritten form working in the wild?

It seems like the syntax is fine but I can't actually import the value of ns from use.ts.

// example-1.ts
import { Greeting } from "./use.ts";

let greeting: Greeting = { greet: "hi" };

Greeting.hello(greeting);
// 'Greeting' only refers to a type, but is being used as a value here.

Oddly enough, it seems to work when I import the entire module with a wildcard.

// example-2.ts
import * as Use from "./use.ts";

let greeting: Use.Greeting = { greet: "hi" };

Use.Greeting.hello(greeting);

I had been using the following workaround:

// use.ts

import * as ns from "./ns";

export const Greeting = ns;
export type Greeting = ns.Greeting;

But I've just discovered that it breaks tree shaking for Rollup (and presumably other bundlers). Anything that imports use.ts will end up with a full copy of the ns.ts module, irrespective of which exports they're actually using.

The important difference seems to be that tree shaking only works when the values are re-exported directly.

// works with tree shaking, not with typescript
export { ns as Greeting };

// works with typescript, not with tree shaking
export const Greeting = ns.Greeting;

This is possibly a separate issue to the original report, but I'm not sure. Here's a repro for anyone who can dig further than I can https://github.com/danprince/ts-export-types-bug

[garrettm]

Hmm curious, I'm not having any luck with the latest non-beta TSC with @andrewbranch's workaround anymore either. Maybe I had a slightly different setup, or maybe this changed in a 3.8.x?

Your workaround does work for me @danprince

It would be nice if this was more ergonomic in general in typescript

[garrettm]

One downside of @danprince's workaround is that you can't export types from the namespace, you get this error when you try to use it:
'Editor' only refers to a type, but is being used as a namespace here.