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

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?

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).

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.

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.

🙌

Mohamed Hegazy (@mhegazy)

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!

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.

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:

moduleC needs to have a hard dependency of moduleA and import ABC
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

Vladimir Matveev (@vladima)

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

you do not need an interface, you just need to import the types:

Mapping.ts:

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

...

Edit: fixed the sample above, thanks for Vladimir Matveev (@vladima) for point out.

Just came across this issue today after upgrading Angular-CLI.

Needless to say, from my perspective as a "naive" developer, the requirement that implicitly used interfaces be imported everywhere has the serious downside of poor developer tooling support. At least in WebStorm using the TypeScript service, the imported interfaces are shown as being unused and thus subject to removal by other developers or automatic removal whenever Optimize Imports is executed. Aside from that it is extremely non-obvious, from the wording of the error message, how the problem can be fixed.

microsoft/TypeScript#9944 compact selenium-webdriver types v2, hope @…

fixed ts declaration issue

Wesley Wigham (@weswigham)

Wesley Wigham (@weswigham) I'm on typescript v3.3.0-dev.20181129, and it looks like this issue is not completely fixed.

The following issue has a sample of what my code looks like along with the problem described here: #28754 (comment)

Unfortunately I am not able to make a small reproduction, and I can't share the larger private code where it is happening.

The strange thing is that it only happens in some files, but not all of them.

remove unused imports

fix: export interface

For me, the error was simply that I had no declared an import at all.

import styled from 'styled-components'
styled was completely undefined, but instead of a normal JS error I got a TS error.

Be explicit about return types to avoid tsc complaints

Update mixins to avoid compilation issues

Don't wanna bring this issue up again but I'm really struggling with this error. I read through the comments but can't really understand my problem & solution provided above.

The error

Exported variable 'useWeb3' has or is using name 'RedBN' from external module "~/sample-project/node_modules/@types/bn.js/index" but cannot be named.

My code:

// example.ts

import Web3 from 'web3';
import { ref, toRefs } from 'vue';

const web3 = ref<null|Web3>(null);
export const useWeb3 = () => {
  return {
    state: toRefs(web3)
  }
}

From what I've read in this issue, I just need to import the RedBN type to my example.ts ? But RedBN was declare locally & have no export then how can I resolve this problem..

Long Nguyen (@8bu)

Long Nguyen (@8bu), Joseph Kohlmann (@kohlmannj), Joe Pea (@trusktr)

I had this for an exported type which is actually just a renamed internal interface which could not be imported/re-exported so I found a work around:

// TSESTreeOptions is exported from library but its actually just a rename of an internal type ParseAndGenerateServicesOptions which is not exported and this causes the error in type resolution
import { TSESTreeOptions as _TSESTreeOptions } from '@typescript-eslint/typescript-estree';

//Clone type and use this type in place of the original for my modules export api/signature
export type TSESTreeOptions = { [K in keyof _TSESTreeOptions]: _TSESTreeOptions[K] }; 

export function doSomething(options: TSESTreeOptions) {
    callFunctionThatRequiresOriginalType(options); //Type resolution should know types are compatible
    callFunctionThatRequiresOriginalType(options as _TSESTreeOptions); //If not, cast to original type
}

This is the original type export from the @typescript-eslint/typescript-estree library.

export declare type TSESTreeOptions = ParseAndGenerateServicesOptions;

but if you find ParseAndGenerateServicesOptions its an internal interface

interface ParseAndGenerateServicesOptions extends ParseOptions {

My theory is this type of export is the issue as typescript sees that TSESTreeOptions = ParseAndGenerateServicesOptions and potentially just treats it as an alias, or it doesn't work when "exported type = internal interface"? Then when it tries to resolve this alias if you import and then export from another module further down the line the alias cannot be resolved because the type is resolves is internal?

This issue makes opaque types very difficult to use in some situations.

declare const norm1_5_sym:unique symbol
export type norm1_5_T<Base extends number = number> =
	Base extends score_T
	? score1_5_T
	: Base extends percentile_T
		? percentile1_5_T
		: Base&{ [norm1_5_sym]:any }

// TS4023: Exported variable 'norm1_5_M_color' has or is using name 'norm1_5_sym' from external module "..." but cannot be named.
export const norm1_5_M_color = Object.freeze(
	new Map<norm1_5_T, string>([
		[null as norm1_5_T, norm1_5__null__color],
		[1 as norm1_5_T, norm1_5__1__color],
		[2 as norm1_5_T, norm1_5__2__color],
		[3 as norm1_5_T, norm1_5__3__color],
		[4 as norm1_5_T, norm1_5__4__color],
		[5 as norm1_5_T, norm1_5__5__color],
	]))

Even adding the following does not fix the TS4023 error:

import type { norm1_5_sym } from '@namespace/types'
type _ = typeof norm1_5_sym

I have not been able to export/import norm1_5_sym to make the error go away. norm1_5_sym is meant to be private to apply the opaque type hack to add typing info to a primitive.

Edit: I was able to fix the issue by extracting a base type from the norm1_5_T definition:

declare const norm1_5_sym:unique symbol
type base__norm1_5_T<Base extends number = number> = Base&{ [norm1_5_sym]:any }
export type norm1_5_T<Base extends number = number> =
	Base extends score_T
	? score1_5_T
	: Base extends percentile_T
		? percentile1_5_T
		: base__norm1_5_T<Base>

Perhaps there's an issue with defining the base norm1_5_T within the conditional logic without there being a type to reference.

Note that score1_5_T & percentile1_5_T are defined as:

declare const percentile_sym:unique symbol
export type percentile_T = number&{ [percentile_sym]:any }
declare const percentile1_5_sym:unique symbol
export type percentile1_5_T = norm1_5_T&percentile_T&{ [percentile1_5_sym]:any }
declare const score_sym:unique symbol
export type score_T = number&{ [score_sym]:any }
declare const score1_5_sym:unique symbol
export type score1_5_T = norm1_5_T&score_T&{ [score1_5_sym]:any }

I don't understand why this is closed. It's still an issue, and the different behavior here between type and interface is obviously a bug from the end-user perspective.

I just encountered this today. I wasn't using a very old version of TypeScript (much later than this issue), so I was surprised to see this error suddenly crop up in a file I wrote not long ago.

Considering the age of this issue, I think I'll have to create a new one to figure out what I'm supposed to do and perhaps a bit of conversation on why I prefer the approach I took rather than the suggested approach. And perhaps there's already another conversation about it.

Locking due to drive-by comments.

Please read https://github.com/Microsoft/TypeScript/wiki/FAQ#the-inferred-type-of-x-cannot-be-named-without-a-reference-to-y-this-is-likely-not-portable-a-type-annotation-is-necessary and log a new issue if you encounter behavior not covered by that FAQ entry.

Navigation Menu

Repository navigation

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

test.ts

tsconfig.json

package.json

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

Mapping.ts:

74 remaining items

The error

My code:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

mijay commented on Sep 2, 2016

test.ts

tsconfig.json

package.json

mhegazy commented on Sep 2, 2016

frederickfogerty commented on Sep 19, 2016

landonpoch commented on Oct 11, 2016

ecraig12345 commented on Oct 19, 2016

unional commented on Oct 19, 2016

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

mhegazy commented on Oct 19, 2016

Mapping.ts:

mischkl commented on Dec 7, 2016

74 remaining items

trusktr commented on Dec 3, 2018

hutber commented on Feb 10, 2020

8bu commented on Feb 10, 2021

The error

My code:

jcbdev commented on Dec 12, 2021

btakita commented on Nov 13, 2022

icopp commented on Apr 2, 2025

cwadrupldijjit commented on Apr 7, 2025

RyanCavanaugh commented on Apr 8, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions