XXX has or is using name 'Foo' from external module "../bar" but cannot be named

[vilicvane]

TypeScript Version: 2.0.0

npm init
npm install clime --save

tsconfig.json

{
 "compilerOptions": {
 "target": "es6",
 "module": "commonjs",
 "emitDecoratorMetadata": true,
 "experimentalDecorators": true,
 "noEmitOnError": true,
 "noImplicitAny": true,
 "noImplicitReturns": true,
 "noImplicitThis": true,
 "strictNullChecks": true,
 "declaration": true,
 "sourceMap": true,
 "rootDir": "src",
 "outDir": "bld"
 },
 "exclude": [
 "node_modules"
 ]
}

src/cli.ts

#!/usr/bin/env node

import * as Path from 'path';
import { CLI, Shim } from 'clime';

let cli = new CLI('henge', Path.join(__dirname, 'commands'));

// This is okay.
export default cli;

// This gives errors:
// TS4023: Exported variable 'foo' has or is using name 'Promise' from external module "C:/Projects/clime/node_modules/thenfail/bld/promise" but cannot be named.
// TS4023: Exported variable 'foo' has or is using name 'Printable' from external module "C:/Projects/clime/bld/core/object" but cannot be named.
let foo = cli.execute([]);
export { foo };

It seems that if I import Printable from clime, the second error would go away, but I cannot import Promise from the dependency of clime.

Is this expected behavior or a bug?

[mijay]

This (or very similar) issue actually completely breaks declaration feature in projects using external typings:

test.ts

import { DOM, Component } from "react";
export class TestMe extends Component<{}, {}> {
// error TS4055: Return type of public method from exported class has or is using private name 'React.DOMElement'.
// error TS4055: Return type of public method from exported class has or is using private name 'React.HTMLAttributes'.
 render() {
 return DOM.div();
 }
}

tsconfig.json

{
 "compilerOptions": {
 "module": "commonjs",
 "target": "es5",
 "moduleResolution": "node",
 "declaration": true
 },
 "files": [ "test.ts" ]
}

package.json

{
 "name": "test",
 "version": "1.0.0",
 "dependencies": {
 "@types/react": "^0.14.31",
 "react": "^15.1.0"
 },
 "devDependencies": {
 "typescript": "^2.0.2"
 }
}

I can fix the errors by explicitly importing DOMElement and HTMLAttributes, but that negate all benefits of type inference - I am basically forced to write all types everywhere (especially with noUnusedLocals).

[mhegazy]

There is no explicit type annotation on the functions or variables. the declaration emitter infers their type and tries to write it. if the type is coming from a different module, then a. it needs to add an import or b. error.

The emitter can write the additional import, but that would have been changing your API shape in a way you did not indicate clearly in your code. so we opted to error instead.

the fix would be to add an explicit type annotation on the source of the problem.

Having siad that, i think we should reconsider this design decision, and add imports anyways.

[frederickfogerty]

Please consider adding adding imports to resolve this error. This is an error which comes up daily in our workflow with TypeScript and would be easier for us if this was never an issue again.

🙌

[landonpoch]

I was able to get around this issue by doing what Mohamed Hegazy (@mhegazy) suggested. After adding an explicit type annotation (my return type was blank and having to get inferred from the parent class) then the errors went away. Worked like a charm. Thanks!

[ecraig12345]

My team at Microsoft is having this issue too, but in our case (a mapping of enum values to functions) it's not reasonable to add explicit types. Here's a greatly simplified version of our scenario:

tsconfig.json:

{
 "compilerOptions": {
 "module": "amd",
 "target": "es5",
 "declaration": true
 }
}

Mapping.ts:

import { fooFunction } from './FooFunction';
import { barFunction } from './BarFunction';

export enum Enum {
 foo,
 bar
}

export const mapping = {
 [Enum.foo]: fooFunction, // error TS4023: Exported variable 'mapping' has or is using name 'IFoo' from external module "D:/test/IFoo" but cannot be named.
 [Enum.bar]: barFunction // error TS4023: Exported variable 'mapping' has or is using name 'IBar' from external module "D:/test/IBar" but cannot be named.
}

FooFunction.ts:

export interface IFoo {
 bar: string;
}
export function fooFunction(foo: IFoo) {
 return foo.bar;
}

BarFunction.ts:

export interface IBar {
 foo: string;
}
export function barFunction(bar: IBar) {
 return bar.foo;
}

An manually written interface for the mapping would be incredibly ugly and hard to maintain (the actual mapping has 20+ values):

interface IMapping {
 "0": (foo: IFoo) => string;
 "1": (bar: IBar) => string;
}

In our case, I worked around the issue by adding the relevant imports to the mapping file and wrapping them in tslint:disable (we disallow unused variables with a lint rule rather than a compiler flag). But it would be better if that wasn't necessary.

[unional]

As a reminder that auto re-export or other mechanisms are needed to properly resolve this issue. Adding import only is not sufficient.

#5711 (comment)

----------- Original comment ----------

This could have deeper consequences.

Consider moduleA -> moduleB -> moduleC -> moduleD.

moduleB is the one that needs to do import { ABC } from 'moduleA' to get around this issue.

When moduleC uses moduleB and export its signature, it again fails to compile because moduleB needs ABC from moduleA but this time moduleB didn't export it.

This means either:

1. moduleC needs to have a hard dependency of moduleA and import ABC
2. moduleB needs to not just import but also re-export ABC and then moduleC imports it.

If moduleD does similar things, then basically you need to know the whole chain of dependencies.

I wasn't able to test this to prove that it is the case because I'm using typings and there is an issue blocking me so: typings/typings#625

EDIT: I am able to reproduce it and indeed my moduleD needs to reference moduleA to import ABC.
In my example:

• moduleA => redux
• moduleB => redux-thunk
• moduleC => custom code on top of redux-thunk
• moduleD => some library
• ABC => Dispatch interface in redux