Enum export not working across multiple projects

[christyharagan]

The error relates to enums, and exports using the new typescript node resolution (with the typings property in the package.json). I have tested this on typescript@next.

The bug can be reproduced through the following scenario: (please go to https://github.com/christyharagan/typeScript-enum-export-bug to find this code):

Three projects: a, b, c.

b depends on a
c depends on b

a exports an enum through its index.ts:

export enum E{}

b then exports a function that returns E through its index.ts:

import {E} from 'a'
export function f():E {
  return null
}

c then consumes f through its index.ts:

import {E} from 'a'
import {f} from 'b'

let e:E = f()

There is now an error for e:

Type 'E' is not assignable to type 'E'.

All three packages have a package.json that looks like this:

{
  "name": "b",
  "version": "1",
  "main": "lib/index.js",
  "typings": "lib/index.d.ts",
  "dependencies": {
    "a": "1"
  }
}

And a tsconfig.json that looks like:

{
    "compilerOptions": {
        "declaration": true,
        "module": "commonjs",
        "rootDir": "./src",
        "target": "es5",
        "outDir": "./lib"
    },
    "files": [
        "src/index.ts"
    ]
}

Furthermore, this defect occurs if f were to export another symbol (e.g. an interface) which references an exported enum somewhere within it's structure or hierarchy.

This only seems to affect enums, not other types.

[mhegazy]

The problem is a/index.ts is loaded twice from two places, node_modules\a and node_modules\b\node_modules\a, and from the compiler perspective they are two different modules.

Enums are not checked structurally, each any two enum types are not assignable to each other, regardless of their shape; other structural checks would work, e.g. passing an interface with he same shape as the expected target type. A class with a private member, however, will behave like an enum, as a private has to originate from the same declaration, and as mentioned above, they are not.

Solutions, npm dedupe should solve this issue, assuming the version of the packages is compatible. the other possible solution would be implementing the suggestion in #4665 (comment).

The typescript resolver should attempt to dedupe packages in similar setup, so marking it as a bug.

[mhegazy]

After discussion this some more, 1. npm v3 and later should flatten by default, so no additional work needed by the compiler, and 2. enums should not be compared nominally, see #5740